David Stevens [Tue, 18 Mar 2014 16:32:29 +0000 (12:32 -0400)]
vxlan: fix potential NULL dereference in arp_reduce()
[ Upstream commit
7346135dcd3f9b57f30a5512094848c678d7143e ]
This patch fixes a NULL pointer dereference in the event of an
skb allocation failure in arp_reduce().
Signed-Off-By: David L Stevens <dlstevens@us.ibm.com>
Acked-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
lucien [Mon, 17 Mar 2014 04:51:01 +0000 (12:51 +0800)]
ipv6: ip6_append_data_mtu do not handle the mtu of the second fragment properly
[ Upstream commit
e367c2d03dba4c9bcafad24688fadb79dd95b218 ]
In ip6_append_data_mtu(), when the xfrm mode is not tunnel(such as
transport),the ipsec header need to be added in the first fragment, so the mtu
will decrease to reserve space for it, then the second fragment come, the mtu
should be turn back, as the commit
0c1833797a5a6ec23ea9261d979aa18078720b74
said. however, in the commit
a493e60ac4bbe2e977e7129d6d8cbb0dd236be, it use
*mtu = min(*mtu, ...) to change the mtu, which lead to the new mtu is alway
equal with the first fragment's. and cannot turn back.
when I test through ping6 -c1 -s5000 $ip (mtu=1280):
...frag (0|1232) ESP(spi=0x00002000,seq=0xb), length 1232
...frag (1232|1216)
...frag (2448|1216)
...frag (3664|1216)
...frag (4880|164)
which should be:
...frag (0|1232) ESP(spi=0x00001000,seq=0x1), length 1232
...frag (1232|1232)
...frag (2464|1232)
...frag (3696|1232)
...frag (4928|116)
so delete the min() when change back the mtu.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Fixes:
75a493e60ac4bb ("ipv6: ip6_append_data_mtu did not care about pmtudisc and frag_size")
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Heiner Kallweit [Wed, 12 Mar 2014 21:13:19 +0000 (22:13 +0100)]
ipv6: Avoid unnecessary temporary addresses being generated
[ Upstream commit
ecab67015ef6e3f3635551dcc9971cf363cc1cd5 ]
tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore
age needs to be added to the condition.
Age calculation in ipv6_create_tempaddr is different from the one
in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.
This can cause age in ipv6_create_tempaddr to be less than the one
in addrconf_verify and therefore unnecessary temporary address to
be generated.
Use age calculation as in addrconf_modify to avoid this.
Signed-off-by: Heiner Kallweit <heiner.kallweit@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Stefan Wahren [Wed, 12 Mar 2014 10:28:19 +0000 (11:28 +0100)]
eth: fec: Fix lost promiscuous mode after reconnecting cable
[ Upstream commit
84fe61821e4ebab6322eeae3f3c27f77f0031978 ]
If the Freescale fec is in promiscuous mode and network cable is
reconnected then the promiscuous mode get lost. The problem is caused
by a too soon call of set_multicast_list to re-enable promisc mode.
The FEC_R_CNTRL register changes are overwritten by fec_restart.
This patch fixes this by moving the call behind the init of FEC_R_CNTRL
register in fec_restart.
Successful tested on a i.MX28 board.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
dingtianhong [Wed, 12 Mar 2014 09:31:59 +0000 (17:31 +0800)]
bonding: set correct vlan id for alb xmit path
[ Upstream commit
fb00bc2e6cd2046282ba4b03f4fe682aee70b2f8 ]
The commit
d3ab3ffd1d728d7ee77340e7e7e2c7cfe6a4013e
(bonding: use rlb_client_info->vlan_id instead of ->tag)
remove the rlb_client_info->tag, but occur some issues,
The vlan_get_tag() will return 0 for success and -EINVAL for
error, so the client_info->vlan_id always be set to 0 if the
vlan_get_tag return 0 for success, so the client_info would
never get a correct vlan id.
We should only set the vlan id to 0 when the vlan_get_tag return error.
Fixes:
d3ab3ffd1d7 (bonding: use rlb_client_info->vlan_id instead of ->tag)
CC: Ding Tianhong <dingtianhong@huawei.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Acked-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Matthew Leach [Tue, 11 Mar 2014 11:58:27 +0000 (11:58 +0000)]
net: socket: error on a negative msg_namelen
[ Upstream commit
dbb490b96584d4e958533fb637f08b557f505657 ]
When copying in a struct msghdr from the user, if the user has set the
msg_namelen parameter to a negative value it gets clamped to a valid
size due to a comparison between signed and unsigned values.
Ensure the syscall errors when the user passes in a negative value.
Signed-off-by: Matthew Leach <matthew.leach@arm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Linus Lüssing [Mon, 10 Mar 2014 21:25:25 +0000 (22:25 +0100)]
bridge: multicast: enable snooping on general queries only
[ Upstream commit
20a599bec95a52fa72432b2376a2ce47c5bb68fb ]
Without this check someone could easily create a denial of service
by injecting multicast-specific queries to enable the bridge
snooping part if no real querier issuing periodic general queries
is present on the link which would result in the bridge wrongly
shutting down ports for multicast traffic as the bridge did not learn
about these listeners.
With this patch the snooping code is enabled upon receiving valid,
general queries only.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Linus Lüssing [Mon, 10 Mar 2014 21:25:24 +0000 (22:25 +0100)]
bridge: multicast: add sanity check for general query destination
[ Upstream commit
9ed973cc40c588abeaa58aea0683ea665132d11d ]
General IGMP and MLD queries are supposed to have the multicast
link-local all-nodes address as their destination according to RFC2236
section 9, RFC3376 section 4.1.12/9.1, RFC2710 section 8 and RFC3810
section 5.1.15.
Without this check, such malformed IGMP/MLD queries can result in a
denial of service: The queries are ignored by most IGMP/MLD listeners
therefore they will not respond with an IGMP/MLD report. However,
without this patch these malformed MLD queries would enable the
snooping part in the bridge code, potentially shutting down the
according ports towards these hosts for multicast traffic as the
bridge did not learn about these listeners.
Reported-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Eric Dumazet [Mon, 10 Mar 2014 16:50:11 +0000 (09:50 -0700)]
tcp: tcp_release_cb() should release socket ownership
[ Upstream commit
c3f9b01849ef3bc69024990092b9f42e20df7797 ]
Lars Persson reported following deadlock :
-000 |M:0x0:0x802B6AF8(asm) <-- arch_spin_lock
-001 |tcp_v4_rcv(skb = 0x8BD527A0) <-- sk = 0x8BE6B2A0
-002 |ip_local_deliver_finish(skb = 0x8BD527A0)
-003 |__netif_receive_skb_core(skb = 0x8BD527A0, ?)
-004 |netif_receive_skb(skb = 0x8BD527A0)
-005 |elk_poll(napi = 0x8C770500, budget = 64)
-006 |net_rx_action(?)
-007 |__do_softirq()
-008 |do_softirq()
-009 |local_bh_enable()
-010 |tcp_rcv_established(sk = 0x8BE6B2A0, skb = 0x87D3A9E0, th = 0x814EBE14, ?)
-011 |tcp_v4_do_rcv(sk = 0x8BE6B2A0, skb = 0x87D3A9E0)
-012 |tcp_delack_timer_handler(sk = 0x8BE6B2A0)
-013 |tcp_release_cb(sk = 0x8BE6B2A0)
-014 |release_sock(sk = 0x8BE6B2A0)
-015 |tcp_sendmsg(?, sk = 0x8BE6B2A0, ?, ?)
-016 |sock_sendmsg(sock = 0x8518C4C0, msg = 0x87D8DAA8, size = 4096)
-017 |kernel_sendmsg(?, ?, ?, ?, size = 4096)
-018 |smb_send_kvec()
-019 |smb_send_rqst(server = 0x87C4D400, rqst = 0x87D8DBA0)
-020 |cifs_call_async()
-021 |cifs_async_writev(wdata = 0x87FD6580)
-022 |cifs_writepages(mapping = 0x852096E4, wbc = 0x87D8DC88)
-023 |__writeback_single_inode(inode = 0x852095D0, wbc = 0x87D8DC88)
-024 |writeback_sb_inodes(sb = 0x87D6D800, wb = 0x87E4A9C0, work = 0x87D8DD88)
-025 |__writeback_inodes_wb(wb = 0x87E4A9C0, work = 0x87D8DD88)
-026 |wb_writeback(wb = 0x87E4A9C0, work = 0x87D8DD88)
-027 |wb_do_writeback(wb = 0x87E4A9C0, force_wait = 0)
-028 |bdi_writeback_workfn(work = 0x87E4A9CC)
-029 |process_one_work(worker = 0x8B045880, work = 0x87E4A9CC)
-030 |worker_thread(__worker = 0x8B045880)
-031 |kthread(_create = 0x87CADD90)
-032 |ret_from_kernel_thread(asm)
Bug occurs because __tcp_checksum_complete_user() enables BH, assuming
it is running from softirq context.
Lars trace involved a NIC without RX checksum support but other points
are problematic as well, like the prequeue stuff.
Problem is triggered by a timer, that found socket being owned by user.
tcp_release_cb() should call tcp_write_timer_handler() or
tcp_delack_timer_handler() in the appropriate context :
BH disabled and socket lock held, but 'owned' field cleared,
as if they were running from timer handlers.
Fixes:
6f458dfb4092 ("tcp: improve latencies of timer triggered events")
Reported-by: Lars Persson <lars.persson@axis.com>
Tested-by: Lars Persson <lars.persson@axis.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Peter Boström [Mon, 10 Mar 2014 15:17:15 +0000 (16:17 +0100)]
vlan: Set correct source MAC address with TX VLAN offload enabled
[ Upstream commit
dd38743b4cc2f86be250eaf156cf113ba3dd531a ]
With TX VLAN offload enabled the source MAC address for frames sent using the
VLAN interface is currently set to the address of the real interface. This is
wrong since the VLAN interface may be configured with a different address.
The bug was introduced in commit
2205369a314e12fcec4781cc73ac9c08fc2b47de
("vlan: Fix header ops passthru when doing TX VLAN offload.").
This patch sets the source address before calling the create function of the
real interface.
Signed-off-by: Peter Boström <peter.bostrom@netrounds.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Eric Dumazet [Fri, 7 Mar 2014 06:57:52 +0000 (22:57 -0800)]
pkt_sched: fq: do not hold qdisc lock while allocating memory
[ Upstream commit
2d8d40afd187bced0a3d056366fb58d66fe845e3 ]
Resizing fq hash table allocates memory while holding qdisc spinlock,
with BH disabled.
This is definitely not good, as allocation might sleep.
We can drop the lock and get it when needed, we hold RTNL so no other
changes can happen at the same time.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes:
afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Michael Chan [Sun, 9 Mar 2014 23:45:32 +0000 (15:45 -0800)]
bnx2: Fix shutdown sequence
[ Upstream commit
a8d9bc2e9f5d1c5a25e33cec096d2a1652d3fd52 ]
The pci shutdown handler added in:
bnx2: Add pci shutdown handler
commit
25bfb1dd4ba3b2d9a49ce9d9b0cd7be1840e15ed
created a shutdown down sequence without chip reset if the device was
never brought up. This can cause the firmware to shutdown the PHY
prematurely and cause MMIO read cycles to be unresponsive. On some
systems, it may generate NMI in the bnx2's pci shutdown handler.
The fix is to tell the firmware not to shutdown the PHY if there was
no prior chip reset.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Sabrina Dubroca [Thu, 6 Mar 2014 16:51:57 +0000 (17:51 +0100)]
ipv6: don't set DST_NOCOUNT for remotely added routes
[ Upstream commit
c88507fbad8055297c1d1e21e599f46960cbee39 ]
DST_NOCOUNT should only be used if an authorized user adds routes
locally. In case of routes which are added on behalf of router
advertisments this flag must not get used as it allows an unlimited
number of routes getting added remotely.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Anton Nayshtut [Wed, 5 Mar 2014 06:30:08 +0000 (08:30 +0200)]
ipv6: Fix exthdrs offload registration.
[ Upstream commit
d2d273ffabd315eecefce21a4391d44b6e156b73 ]
Without this fix, ipv6_exthdrs_offload_init doesn't register IPPROTO_DSTOPTS
offload, but returns 0 (as the IPPROTO_ROUTING registration actually succeeds).
This then causes the ipv6_gso_segment to drop IPv6 packets with IPPROTO_DSTOPTS
header.
The issue detected and the fix verified by running MS HCK Offload LSO test on
top of QEMU Windows guests, as this test sends IPv6 packets with
IPPROTO_DSTOPTS.
Signed-off-by: Anton Nayshtut <anton@swortex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Eric Dumazet [Wed, 26 Mar 2014 01:42:27 +0000 (18:42 -0700)]
net: unix: non blocking recvmsg() should not return -EINTR
[ Upstream commit
de1443916791d75fdd26becb116898277bb0273f ]
Some applications didn't expect recvmsg() on a non blocking socket
could return -EINTR. This possibility was added as a side effect
of commit
b3ca9b02b00704 ("net: fix multithreaded signal handling in
unix recv routines").
To hit this bug, you need to be a bit unlucky, as the u->readlock
mutex is usually held for very small periods.
Fixes:
b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv routines")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Florian Westphal [Thu, 6 Mar 2014 17:06:41 +0000 (18:06 +0100)]
inet: frag: make sure forced eviction removes all frags
[ Upstream commit
e588e2f286ed7da011ed357c24c5b9a554e26595 ]
Quoting Alexander Aring:
While fragmentation and unloading of 6lowpan module I got this kernel Oops
after few seconds:
BUG: unable to handle kernel paging request at
f88bbc30
[..]
Modules linked in: ipv6 [last unloaded: 6lowpan]
Call Trace:
[<
c012af4c>] ? call_timer_fn+0x54/0xb3
[<
c012aef8>] ? process_timeout+0xa/0xa
[<
c012b66b>] run_timer_softirq+0x140/0x15f
Problem is that incomplete frags are still around after unload; when
their frag expire timer fires, we get crash.
When a netns is removed (also done when unloading module), inet_frag
calls the evictor with 'force' argument to purge remaining frags.
The evictor loop terminates when accounted memory ('work') drops to 0
or the lru-list becomes empty. However, the mem accounting is done
via percpu counters and may not be accurate, i.e. loop may terminate
prematurely.
Alter evictor to only stop once the lru list is empty when force is
requested.
Reported-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Reported-by: Alexander Aring <alex.aring@gmail.com>
Tested-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Erik Hugne [Thu, 6 Mar 2014 13:40:21 +0000 (14:40 +0100)]
tipc: don't log disabled tasklet handler errors
[ Upstream commit
2892505ea170094f982516bb38105eac45f274b1 ]
Failure to schedule a TIPC tasklet with tipc_k_signal because the
tasklet handler is disabled is not an error. It means TIPC is
currently in the process of shutting down. We remove the error
logging in this case.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Erik Hugne [Thu, 6 Mar 2014 13:40:20 +0000 (14:40 +0100)]
tipc: fix memory leak during module removal
[ Upstream commit
1bb8dce57f4d15233688c68990852a10eb1cd79f ]
When the TIPC module is removed, the tasklet handler is disabled
before all other subsystems. This will cause lingering publications
in the name table because the node_down tasklets responsible to
clean up publications from an unreachable node will never run.
When the name table is shut down, these publications are detected
and an error message is logged:
tipc: nametbl_stop(): orphaned hash chain detected
This is actually a memory leak, introduced with commit
993b858e37b3120ee76d9957a901cca22312ffaa ("tipc: correct the order
of stopping services at rmmod")
Instead of just logging an error and leaking memory, we free
the orphaned entries during nametable shutdown.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Erik Hugne [Thu, 6 Mar 2014 13:40:19 +0000 (14:40 +0100)]
tipc: drop subscriber connection id invalidation
[ Upstream commit
edcc0511b5ee7235282a688cd604e3ae7f9e1fc9 ]
When a topology server subscriber is disconnected, the associated
connection id is set to zero. A check vs zero is then done in the
subscription timeout function to see if the subscriber have been
shut down. This is unnecessary, because all subscription timers
will be cancelled when a subscriber terminates. Setting the
connection id to zero is actually harmful because id zero is the
identity of the topology server listening socket, and can cause a
race that leads to this socket being closed instead.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Ying Xue [Thu, 6 Mar 2014 13:40:17 +0000 (14:40 +0100)]
tipc: fix connection refcount leak
[ Upstream commit
4652edb70e8a7eebbe47fa931940f65522c36e8f ]
When tipc_conn_sendmsg() calls tipc_conn_lookup() to query a
connection instance, its reference count value is increased if
it's found. But subsequently if it's found that the connection is
closed, the work of sending message is not queued into its server
send workqueue, and the connection reference count is not decreased.
This will cause a reference count leak. To reproduce this problem,
an application would need to open and closes topology server
connections with high intensity.
We fix this by immediately decrementing the connection reference
count if a send fails due to the connection being closed.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Ying Xue [Thu, 6 Mar 2014 13:40:16 +0000 (14:40 +0100)]
tipc: allow connection shutdown callback to be invoked in advance
[ Upstream commit
6d4ebeb4df0176b1973875840a9f7e91394c0685 ]
Currently connection shutdown callback function is called when
connection instance is released in tipc_conn_kref_release(), and
receiving packets and sending packets are running in different
threads. Even if connection is closed by the thread of receiving
packets, its shutdown callback may not be called immediately as
the connection reference count is non-zero at that moment. So,
although the connection is shut down by the thread of receiving
packets, the thread of sending packets doesn't know it. Before
its shutdown callback is invoked to tell the sending thread its
connection has been closed, the sending thread may deliver
messages by tipc_conn_sendmsg(), this is why the following error
information appears:
"Sending subscription event failed, no memory"
To eliminate it, allow connection shutdown callback function to
be called before connection id is removed in tipc_close_conn(),
which makes the sending thread know the truth in time that its
socket is closed so that it doesn't send message to it. We also
remove the "Sending XXX failed..." error reporting for topology
and config services.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Linus Lüssing [Tue, 4 Mar 2014 02:57:35 +0000 (03:57 +0100)]
bridge: multicast: add sanity check for query source addresses
[ Upstream commit
6565b9eeef194afbb3beec80d6dd2447f4091f8c ]
MLD queries are supposed to have an IPv6 link-local source address
according to RFC2710, section 4 and RFC3810, section 5.1.14. This patch
adds a sanity check to ignore such broken MLD queries.
Without this check, such malformed MLD queries can result in a
denial of service: The queries are ignored by any MLD listener
therefore they will not respond with an MLD report. However,
without this patch these malformed MLD queries would enable the
snooping part in the bridge code, potentially shutting down the
according ports towards these hosts for multicast traffic as the
bridge did not learn about these listeners.
Reported-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Daniel Borkmann [Tue, 4 Mar 2014 15:35:51 +0000 (16:35 +0100)]
net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk
[ Upstream commit
c485658bae87faccd7aed540fd2ca3ab37992310 ]
While working on
ec0223ec48a9 ("net: sctp: fix sctp_sf_do_5_1D_ce to
verify if we/peer is AUTH capable"), we noticed that there's a skb
memory leakage in the error path.
Running the same reproducer as in
ec0223ec48a9 and by unconditionally
jumping to the error label (to simulate an error condition) in
sctp_sf_do_5_1D_ce() receive path lets kmemleak detector bark about
the unfreed chunk->auth_chunk skb clone:
Unreferenced object 0xffff8800b8f3a000 (size 256):
comm "softirq", pid 0, jiffies
4294769856 (age 110.757s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
89 ab 75 5e d4 01 58 13 00 00 00 00 00 00 00 00 ..u^..X.........
backtrace:
[<
ffffffff816660be>] kmemleak_alloc+0x4e/0xb0
[<
ffffffff8119f328>] kmem_cache_alloc+0xc8/0x210
[<
ffffffff81566929>] skb_clone+0x49/0xb0
[<
ffffffffa0467459>] sctp_endpoint_bh_rcv+0x1d9/0x230 [sctp]
[<
ffffffffa046fdbc>] sctp_inq_push+0x4c/0x70 [sctp]
[<
ffffffffa047e8de>] sctp_rcv+0x82e/0x9a0 [sctp]
[<
ffffffff815abd38>] ip_local_deliver_finish+0xa8/0x210
[<
ffffffff815a64af>] nf_reinject+0xbf/0x180
[<
ffffffffa04b4762>] nfqnl_recv_verdict+0x1d2/0x2b0 [nfnetlink_queue]
[<
ffffffffa04aa40b>] nfnetlink_rcv_msg+0x14b/0x250 [nfnetlink]
[<
ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
[<
ffffffffa04aa7cf>] nfnetlink_rcv+0x23f/0x408 [nfnetlink]
[<
ffffffff815a2bd8>] netlink_unicast+0x168/0x250
[<
ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
[<
ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
[<
ffffffff8155d449>] ___sys_sendmsg+0x369/0x380
What happens is that commit
bbd0d59809f9 clones the skb containing
the AUTH chunk in sctp_endpoint_bh_rcv() when having the edge case
that an endpoint requires COOKIE-ECHO chunks to be authenticated:
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
------------------ AUTH; COOKIE-ECHO ---------------->
<-------------------- COOKIE-ACK ---------------------
When we enter sctp_sf_do_5_1D_ce() and before we actually get to
the point where we process (and subsequently free) a non-NULL
chunk->auth_chunk, we could hit the "goto nomem_init" path from
an error condition and thus leave the cloned skb around w/o
freeing it.
The fix is to centrally free such clones in sctp_chunk_destroy()
handler that is invoked from sctp_chunk_free() after all refs have
dropped; and also move both kfree_skb(chunk->auth_chunk) there,
so that chunk->auth_chunk is either NULL (since sctp_chunkify()
allocs new chunks through kmem_cache_zalloc()) or non-NULL with
a valid skb pointer. chunk->skb and chunk->auth_chunk are the
only skbs in the sctp_chunk structure that need to be handeled.
While at it, we should use consume_skb() for both. It is the same
as dev_kfree_skb() but more appropriately named as we are not
a device but a protocol. Also, this effectively replaces the
kfree_skb() from both invocations into consume_skb(). Functions
are the same only that kfree_skb() assumes that the frame was
being dropped after a failure (e.g. for tools like drop monitor),
usage of consume_skb() seems more appropriate in function
sctp_chunk_destroy() though.
Fixes:
bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Vlad Yasevich <yasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Nikolay Aleksandrov [Mon, 3 Mar 2014 22:19:18 +0000 (23:19 +0100)]
net: fix for a race condition in the inet frag code
[ Upstream commit
24b9bf43e93e0edd89072da51cf1fab95fc69dec ]
I stumbled upon this very serious bug while hunting for another one,
it's a very subtle race condition between inet_frag_evictor,
inet_frag_intern and the IPv4/6 frag_queue and expire functions
(basically the users of inet_frag_kill/inet_frag_put).
What happens is that after a fragment has been added to the hash chain
but before it's been added to the lru_list (inet_frag_lru_add) in
inet_frag_intern, it may get deleted (either by an expired timer if
the system load is high or the timer sufficiently low, or by the
fraq_queue function for different reasons) before it's added to the
lru_list, then after it gets added it's a matter of time for the
evictor to get to a piece of memory which has been freed leading to a
number of different bugs depending on what's left there.
I've been able to trigger this on both IPv4 and IPv6 (which is normal
as the frag code is the same), but it's been much more difficult to
trigger on IPv4 due to the protocol differences about how fragments
are treated.
The setup I used to reproduce this is: 2 machines with 4 x 10G bonded
in a RR bond, so the same flow can be seen on multiple cards at the
same time. Then I used multiple instances of ping/ping6 to generate
fragmented packets and flood the machines with them while running
other processes to load the attacked machine.
*It is very important to have the _same flow_ coming in on multiple CPUs
concurrently. Usually the attacked machine would die in less than 30
minutes, if configured properly to have many evictor calls and timeouts
it could happen in 10 minutes or so.
An important point to make is that any caller (frag_queue or timer) of
inet_frag_kill will remove both the timer refcount and the
original/guarding refcount thus removing everything that's keeping the
frag from being freed at the next inet_frag_put. All of this could
happen before the frag was ever added to the LRU list, then it gets
added and the evictor uses a freed fragment.
An example for IPv6 would be if a fragment is being added and is at
the stage of being inserted in the hash after the hash lock is
released, but before inet_frag_lru_add executes (or is able to obtain
the lru lock) another overlapping fragment for the same flow arrives
at a different CPU which finds it in the hash, but since it's
overlapping it drops it invoking inet_frag_kill and thus removing all
guarding refcounts, and afterwards freeing it by invoking
inet_frag_put which removes the last refcount added previously by
inet_frag_find, then inet_frag_lru_add gets executed by
inet_frag_intern and we have a freed fragment in the lru_list.
The fix is simple, just move the lru_add under the hash chain locked
region so when a removing function is called it'll have to wait for
the fragment to be added to the lru_list, and then it'll remove it (it
works because the hash chain removal is done before the lru_list one
and there's no window between the two list adds when the frag can get
dropped). With this fix applied I couldn't kill the same machine in 24
hours with the same setup.
Fixes:
3ef0eb0db4bf ("net: frag, move LRU list maintenance outside of
rwlock")
CC: Florian Westphal <fw@strlen.de>
CC: Jesper Dangaard Brouer <brouer@redhat.com>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Gerd Hoffmann [Fri, 11 Oct 2013 08:01:09 +0000 (10:01 +0200)]
drm/cirrus: use drm_set_preferred_mode
commit
121a6a17439b000b9699c3fa876636db20fa4107 upstream.
Explicitly set 1024x768 as default mode, so the display doesn't come up
with the largest supported mode.
While being at it drop first three drm_add_modes_noedid calls. As
drm_add_modes_noedid fills the mode list with modes from the database
*up to* the specified size it is pretty pointless to call it multiple
times with different sizes.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Gerd Hoffmann [Fri, 11 Oct 2013 08:01:08 +0000 (10:01 +0200)]
drm: add drm_set_preferred_mode
commit
3cf70dafd7bbbc91df0a9ecb081d46f9f3d867f6 upstream.
New helper function to set the preferred video mode. Can be called
after drm_add_modes_noedid if you don't want the largest supported
video mode be used by default.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Adam Jackson [Wed, 12 Feb 2014 21:02:02 +0000 (16:02 -0500)]
fbdev: Make the switch from generic to native driver less alarming
commit
13ba0ad4490c3dd08b15c430a7a01c6fb45d5bce upstream.
Calling this "conflicting" just makes people think there's a problem
when there's not.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Chris Wilson [Mon, 16 Dec 2013 15:57:39 +0000 (15:57 +0000)]
video/fb: Propagate error code from failing to unregister conflicting fb
commit
46eeb2c144956e88197439b5ee5cf221a91b0a81 upstream.
If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Gu Zheng [Tue, 5 Nov 2013 10:00:57 +0000 (18:00 +0800)]
fb: reorder the lock sequence to fix potential dead lock
commit
3a41c5dbe8bc396a7fb16ca8739e945bb003342e upstream.
Following commits:
50e244cc79 fb: rework locking to fix lock ordering on takeover
e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
054430e773 fbcon: fix locking harder
reworked locking to fix related lock ordering on takeover, and introduced console_lock
into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
a potential dead lock as following:
[ 601.079000] ======================================================
[ 601.079000] [ INFO: possible circular locking dependency detected ]
[ 601.079000] 3.11.0 #189 Not tainted
[ 601.079000] -------------------------------------------------------
[ 601.079000] kworker/0:3/619 is trying to acquire lock:
[ 601.079000] (&fb_info->lock){+.+.+.}, at: [<
ffffffff81397566>] lock_fb_info+0x26/0x60
[ 601.079000]
but task is already holding lock:
[ 601.079000] (console_lock){+.+.+.}, at: [<
ffffffff8141aae3>] console_callback+0x13/0x160
[ 601.079000]
which lock already depends on the new lock.
[ 601.079000]
the existing dependency chain (in reverse order) is:
[ 601.079000]
-> #1 (console_lock){+.+.+.}:
[ 601.079000] [<
ffffffff810dc971>] lock_acquire+0xa1/0x140
[ 601.079000] [<
ffffffff810c6267>] console_lock+0x77/0x80
[ 601.079000] [<
ffffffff81399448>] register_framebuffer+0x1d8/0x320
[ 601.079000] [<
ffffffff81cfb4c8>] efifb_probe+0x408/0x48f
[ 601.079000] [<
ffffffff8144a963>] platform_drv_probe+0x43/0x80
[ 601.079000] [<
ffffffff8144853b>] driver_probe_device+0x8b/0x390
[ 601.079000] [<
ffffffff814488eb>] __driver_attach+0xab/0xb0
[ 601.079000] [<
ffffffff814463bd>] bus_for_each_dev+0x5d/0xa0
[ 601.079000] [<
ffffffff81447e6e>] driver_attach+0x1e/0x20
[ 601.079000] [<
ffffffff81447a07>] bus_add_driver+0x117/0x290
[ 601.079000] [<
ffffffff81448fea>] driver_register+0x7a/0x170
[ 601.079000] [<
ffffffff8144a10a>] __platform_driver_register+0x4a/0x50
[ 601.079000] [<
ffffffff8144a12d>] platform_driver_probe+0x1d/0xb0
[ 601.079000] [<
ffffffff81cfb0a1>] efifb_init+0x273/0x292
[ 601.079000] [<
ffffffff81002132>] do_one_initcall+0x102/0x1c0
[ 601.079000] [<
ffffffff81cb80a6>] kernel_init_freeable+0x15d/0x1ef
[ 601.079000] [<
ffffffff8166d2de>] kernel_init+0xe/0xf0
[ 601.079000] [<
ffffffff816914ec>] ret_from_fork+0x7c/0xb0
[ 601.079000]
-> #0 (&fb_info->lock){+.+.+.}:
[ 601.079000] [<
ffffffff810dc1d8>] __lock_acquire+0x1e18/0x1f10
[ 601.079000] [<
ffffffff810dc971>] lock_acquire+0xa1/0x140
[ 601.079000] [<
ffffffff816835ca>] mutex_lock_nested+0x7a/0x3b0
[ 601.079000] [<
ffffffff81397566>] lock_fb_info+0x26/0x60
[ 601.079000] [<
ffffffff813a4aeb>] fbcon_blank+0x29b/0x2e0
[ 601.079000] [<
ffffffff81418658>] do_blank_screen+0x1d8/0x280
[ 601.079000] [<
ffffffff8141ab34>] console_callback+0x64/0x160
[ 601.079000] [<
ffffffff8108d855>] process_one_work+0x1f5/0x540
[ 601.079000] [<
ffffffff8108e04c>] worker_thread+0x11c/0x370
[ 601.079000] [<
ffffffff81095fbd>] kthread+0xed/0x100
[ 601.079000] [<
ffffffff816914ec>] ret_from_fork+0x7c/0xb0
[ 601.079000]
other info that might help us debug this:
[ 601.079000] Possible unsafe locking scenario:
[ 601.079000] CPU0 CPU1
[ 601.079000] ---- ----
[ 601.079000] lock(console_lock);
[ 601.079000] lock(&fb_info->lock);
[ 601.079000] lock(console_lock);
[ 601.079000] lock(&fb_info->lock);
[ 601.079000]
*** DEADLOCK ***
so we reorder the lock sequence the same as it in console_callback() to
avoid this issue. And following Tomi's suggestion, fix these similar
issues all in fb subsystem.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Takashi Iwai [Wed, 19 Mar 2014 13:53:13 +0000 (14:53 +0100)]
drm: Prefer noninterlace cmdline mode unless explicitly specified
commit
c683f427bdc43525f61e26609d34e799e7ea4c12 upstream.
Currently drm_pick_cmdline_mode() doesn't care about the interlace
when the given mode line has no "i" suffix. That is, when there are
multiple entries for the same resolution, an interlace mode might be
picked up just depending on the assigned order, and there is no way to
exclude it.
This patch changes the logic for the mode selection, to prefer the
noninterlace mode unless the interlace mode is explicitly given.
When no matching mode is found, it still tries the interlace mode as
fallback.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Alex Deucher [Tue, 18 Feb 2014 16:12:11 +0000 (11:12 -0500)]
drm/radeon: enable speaker allocation setup on dce3.2
commit
3803c8e5b50946dd6bc18972d9190757d05648f0 upstream.
Now that we disable audio while setting up the audio
hw, we should be able to set this up without hangs.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Alex Deucher [Tue, 18 Feb 2014 16:07:55 +0000 (11:07 -0500)]
drm/radeon: change audio enable logic
commit
832eafaf34ff7d0348fe701e417900c6cf1f5656 upstream.
Disable audio around audio hw setup. This may avoid
hangs on certain asics.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Martin Koegler [Thu, 9 Jan 2014 09:05:07 +0000 (10:05 +0100)]
drm/cirrus: Fix cirrus drm driver for fbdev + qemu
commit
99d4a8ae93ead27b5a88cdbd09dc556fe96ac3a8 upstream.
Xorg fbdev driver requires smem_start/smem_len, otherwise
it tries to map 0 bytes as video memory.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856760
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Chris Wilson [Tue, 8 Oct 2013 10:16:59 +0000 (11:16 +0100)]
drm/i915: Undo the PIPEA quirk for i845
commit
a4945f9522d27e1e6d64a02ad055e83768cb0896 upstream.
The PIPEA quirk is specifically for the issue with the PIPEB PLL on
830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA
running. i845 doesn't even have the second PLL or pipe, and enabling
the quirk results in a blank DVO LVDS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Jiri Kosina [Fri, 10 Jan 2014 01:08:13 +0000 (02:08 +0100)]
floppy: bail out in open() if drive is not responding to block0 read
commit
7b7b68bba5ef23734c35ffb0d8d82079ed604d33 upstream.
In case reading of block 0 during open() fails, it is not the right thing
to let open() succeed.
Fix this by introducing FD_OPEN_SHOULD_FAIL_BIT flag, and setting it in
case the bio callback encounters an error while trying to read block 0.
As a bonus, this works around certain broken userspace (blkid), which is
not able to properly handle read()s returning IO errors. Hence be nice to
those, and bail out during open() already; if block 0 is not readable,
read()s are not going to provide any meaningful data anyway.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Jan Kara [Tue, 4 Mar 2014 15:50:50 +0000 (10:50 -0500)]
ext4: Speedup WB_SYNC_ALL pass called from sync(2)
commit
10542c229a4e8e25b40357beea66abe9dacda2c0 upstream.
When doing filesystem wide sync, there's no need to force transaction
commit (or synchronously write inode buffer) separately for each inode
because ext4_sync_fs() takes care of forcing commit at the end (VFS
takes care of flushing buffer cache, respectively). Most of the time
this slowness doesn't manifest because previous WB_SYNC_NONE writeback
doesn't leave much to write but when there are processes aggressively
creating new files and several filesystems to sync, the sync slowness
can be noticeable. In the following test script sync(1) takes around 6
minutes when there are two ext4 filesystems mounted on a standard SATA
drive. After this patch sync takes a couple of seconds so we have about
two orders of magnitude improvement.
function run_writers
{
for (( i = 0; i < 10; i++ )); do
mkdir $1/dir$i
for (( j = 0; j < 40000; j++ )); do
dd if=/dev/zero of=$1/dir$i/$j bs=4k count=4 &>/dev/null
done &
done
}
for dir in "$@"; do
run_writers $dir
done
sleep 40
time sync
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Trond Myklebust [Tue, 11 Feb 2014 18:56:54 +0000 (13:56 -0500)]
SUNRPC: Fix potential memory scribble in xprt_free_bc_request()
commit
628356791b04ea988fee070f66a748a823d001bb upstream.
The call to xprt_free_allocation() will call list_del() on
req->rq_bc_pa_list, which is not attached to a list.
This patch moves the list_del() out of xprt_free_allocation()
and into those callers that need it.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Trond Myklebust [Sun, 2 Feb 2014 19:36:42 +0000 (14:36 -0500)]
NFSv3: Fix return value of nfs3_proc_setacls
commit
8f493b9cfcd8941c6b27d6ce8e3b4a78c094b3c1 upstream.
nfs3_proc_setacls is used internally by the NFSv3 create operations
to set the acl after the file has been created. If the operation
fails because the server doesn't support acls, then it must return '0',
not -EOPNOTSUPP.
Reported-by: Russell King <linux@arm.linux.org.uk>
Link: http://lkml.kernel.org/r/20140201010328.GI15937@n2100.arm.linux.org.uk
Cc: Christoph Hellwig <hch@lst.de>
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Acked-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Malahal Naineni [Mon, 27 Jan 2014 21:31:09 +0000 (15:31 -0600)]
nfs: initialize the ACL support bits to zero.
commit
a1800acaf7d1c2bf6d68b9a8f4ab8560cc66555a upstream.
Avoid returning incorrect acl mask attributes when the server doesn't
support ACLs.
Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Jiri Slaby [Mon, 14 Apr 2014 14:46:50 +0000 (09:46 -0500)]
Char: ipmi_bt_sm, fix infinite loop
commit
a94cdd1f4d30f12904ab528152731fb13a812a16 upstream.
In read_all_bytes, we do
unsigned char i;
...
bt->read_data[0] = BMC2HOST;
bt->read_count = bt->read_data[0];
...
for (i = 1; i <= bt->read_count; i++)
bt->read_data[i] = BMC2HOST;
If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the
'for' loop. Make 'i' an 'int' instead of 'char' to get rid of the
overflow and finish the loop after 255 iterations every time.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-debugged-by: Rui Hui Dian <rhdian@novell.com>
Cc: Tomas Cech <tcech@suse.cz>
Cc: Corey Minyard <minyard@acm.org>
Cc: <openipmi-developer@lists.sourceforge.net>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Finn Thain [Wed, 5 Mar 2014 23:29:27 +0000 (10:29 +1100)]
m68k: Skip futex_atomic_cmpxchg_inatomic() test
commit
e571c58f313d35c56e0018470e3375ddd1fd320e upstream.
Skip the futex_atomic_cmpxchg_inatomic() test in futex_init(). It causes a
fatal exception on 68030 (and presumably 68020 also).
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1403061006440.5525@nippy.intranet
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Heiko Carstens [Sun, 2 Mar 2014 12:09:47 +0000 (13:09 +0100)]
futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test
commit
03b8c7b623c80af264c4c8d6111e5c6289933666 upstream.
If an architecture has futex_atomic_cmpxchg_inatomic() implemented and there
is no runtime check necessary, allow to skip the test within futex_init().
This allows to get rid of some code which would always give the same result,
and also allows the compiler to optimize a couple of if statements away.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Finn Thain <fthain@telegraphics.com.au>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: http://lkml.kernel.org/r/20140302120947.GA3641@osiris
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[geert: Backported to v3.10..v3.13]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Paul Moore [Wed, 19 Mar 2014 20:46:18 +0000 (16:46 -0400)]
selinux: correctly label /proc inodes in use before the policy is loaded
commit
f64410ec665479d7b4b77b7519e814253ed0f686 upstream.
This patch is based on an earlier patch by Eric Paris, he describes
the problem below:
"If an inode is accessed before policy load it will get placed on a
list of inodes to be initialized after policy load. After policy
load we call inode_doinit() which calls inode_doinit_with_dentry()
on all inodes accessed before policy load. In the case of inodes
in procfs that means we'll end up at the bottom where it does:
/* Default to the fs superblock SID. */
isec->sid = sbsec->sid;
if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
if (opt_dentry) {
isec->sclass = inode_mode_to_security_class(...)
rc = selinux_proc_get_sid(opt_dentry,
isec->sclass,
&sid);
if (rc)
goto out_unlock;
isec->sid = sid;
}
}
Since opt_dentry is null, we'll never call selinux_proc_get_sid()
and will leave the inode labeled with the label on the superblock.
I believe a fix would be to mimic the behavior of xattrs. Look
for an alias of the inode. If it can't be found, just leave the
inode uninitialized (and pick it up later) if it can be found, we
should be able to call selinux_proc_get_sid() ..."
On a system exhibiting this problem, you will notice a lot of files in
/proc with the generic "proc_t" type (at least the ones that were
accessed early in the boot), for example:
# ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax
However, with this patch in place we see the expected result:
# ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Sebastian Hesselbarth [Tue, 13 Aug 2013 12:25:20 +0000 (14:25 +0200)]
PCI: mvebu: move clock enable before register access
commit
b42285f66f871a9898a0e79e2d74bc7e7a101995 upstream.
The clock passed to PCI controller found on MVEBU SoCs may come from a
clock gate. This requires the clock to be enabled before any registers
are accessed. Therefore, move the clock enable before register iomap to
ensure it is enabled.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Mikulas Patocka [Sun, 13 Apr 2014 14:22:21 +0000 (16:22 +0200)]
powernow-k6: reorder frequencies
commit
22c73795b101597051924556dce019385a1e2fa0 upstream.
This patch reorders reported frequencies from the highest to the lowest,
just like in other frequency drivers.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Mikulas Patocka [Sun, 13 Apr 2014 14:22:20 +0000 (16:22 +0200)]
powernow-k6: correctly initialize default parameters
commit
d82b922a4acc1781d368aceac2f9da43b038cab2 upstream.
The powernow-k6 driver used to read the initial multiplier from the
powernow register. However, there is a problem with this:
* If there was a frequency transition before, the multiplier read from the
register corresponds to the current multiplier.
* If there was no frequency transition since reset, the field in the
register always reads as zero, regardless of the current multiplier that
is set using switches on the mainboard and that the CPU is running at.
The zero value corresponds to multiplier 4.5, so as a consequence, the
powernow-k6 driver always assumes multiplier 4.5.
For example, if we have 550MHz CPU with bus frequency 100MHz and
multiplier 5.5, the powernow-k6 driver thinks that the multiplier is 4.5
and bus frequency is 122MHz. The powernow-k6 driver then sets the
multiplier to 4.5, underclocking the CPU to 450MHz, but reports the
current frequency as 550MHz.
There is no reliable way how to read the initial multiplier. I modified
the driver so that it contains a table of known frequencies (based on
parameters of existing CPUs and some common overclocking schemes) and sets
the multiplier according to the frequency. If the frequency is unknown
(because of unusual overclocking or underclocking), the user must supply
the bus speed and maximum multiplier as module parameters.
This patch should be backported to all stable kernels. If it doesn't
apply cleanly, change it, or ask me to change it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Mikulas Patocka [Sun, 13 Apr 2014 14:22:20 +0000 (16:22 +0200)]
powernow-k6: disable cache when changing frequency
commit
e20e1d0ac02308e2211306fc67abcd0b2668fb8b upstream.
I found out that a system with k6-3+ processor is unstable during network
server load. The system locks up or the network card stops receiving. The
reason for the instability is the CPU frequency scaling.
During frequency transition the processor is in "EPM Stop Grant" state.
The documentation says that the processor doesn't respond to inquiry
requests in this state. Consequently, coherency of processor caches and
bus master devices is not maintained, causing the system instability.
This patch flushes the cache during frequency transition. It fixes the
instability.
Other minor changes:
* u64 invalue changed to unsigned long because the variable is 32-bit
* move the logic to set the multiplier to a separate function
powernow_k6_set_cpu_multiplier
* preserve lower 5 bits of the powernow port instead of 4 (the voltage
field has 5 bits)
* mask interrupts when reading the multiplier, so that the port is not
open during other activity (running other kernel code with the port open
shouldn't cause any misbehavior, but we should better be safe and keep
the port closed)
This patch should be backported to all stable kernels. If it doesn't
apply cleanly, change it, or ask me to change it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
SeokYeon Hwang [Wed, 30 Apr 2014 01:06:58 +0000 (18:06 -0700)]
Merge "Revert "maru_fb : Add a framebuffer device for Tizen emulator"" into tizen_linux_3.12
SeokYeon Hwang [Tue, 29 Apr 2014 11:17:49 +0000 (04:17 -0700)]
Merge "power_supply: disable power_supply & added dependency" into tizen_linux_3.12
Jinhyung Choi [Tue, 29 Apr 2014 06:54:11 +0000 (15:54 +0900)]
power_supply: disable power_supply & added dependency
Change-Id: Ibf1f83c041214f6e06e19c3ad438363056c6db40
Signed-off-by: Jinhyung Choi <jinhyung2.choi@samsung.com>
jinhyung.jo [Tue, 29 Apr 2014 07:36:38 +0000 (16:36 +0900)]
Revert "maru_fb : Add a framebuffer device for Tizen emulator"
This reverts commit
7fafa6cf5c264b9fd55bc009373498f087fabf5b.
Remove maru_fb driver, no more used in tizen emulator.
From now on, VIGS device is used.
Change-Id: Ib915e145cfca09b51a9a5c9c5121e75253941eca
Signed-off-by: Jinhyung Jo <jinhyung.jo@samsung.com>
jinhyung.jo [Wed, 23 Apr 2014 09:04:36 +0000 (18:04 +0900)]
Revert "VirtGL : Add a GL passthrough device for Tizen emulator"
This reverts commit
064e8cb1771fe39a7ca4deb4f5439aac37b0241e.
Remove VirtGL driver, no more used in tizen emulator.
Change-Id: I06746af1675645e736cc77e91a2898dc86c3e3a1
Signed-off-by: Jinhyung Jo <jinhyung.jo@samsung.com>
sangho1206.park [Thu, 24 Apr 2014 02:57:46 +0000 (11:57 +0900)]
config: useful ftrace features enabled
kprobe, uprobe, irqflag, max_trace, function, irqsoff, preempt, sched,
snapshot, stack and mmiotrace are enabled.
Change-Id: I0bd3b778ecdf549806b4a222fcd2ebb6b59bd587
Signed-off-by: sangho1206.park <sangho1206.park@samsung.com>
SeokYeon Hwang [Thu, 17 Apr 2014 08:40:59 +0000 (17:40 +0900)]
sdcard: Provide type "SD" for virtio sdcard.
Change-Id: Idba9d8a748245e3ff1f24e6f5e3843dfd26da76f
Signed-off-by: SeokYeon Hwang <syeon.hwang@samsung.com>
SeokYeon Hwang [Thu, 17 Apr 2014 06:12:39 +0000 (15:12 +0900)]
sdcard: bug fix.
Change-Id: I5a9527253595a6ff26b968e1dedac631f73706bb
Signed-off-by: SeokYeon Hwang <syeon.hwang@samsung.com>
SeokYeon Hwang [Tue, 15 Apr 2014 08:50:56 +0000 (01:50 -0700)]
Merge "sdcard: Prepare mmcblk index more than 0." into tizen_linux_3.12
SeokYeon Hwang [Tue, 15 Apr 2014 03:15:10 +0000 (12:15 +0900)]
sdcard: Prepare mmcblk index more than 0.
Tizen platform can recognize as a "sdcard" when device name starts with "mmcblk".
Change-Id: I05f84984d589eada760390704805cec37947403d
Signed-off-by: SeokYeon Hwang <syeon.hwang@samsung.com>
GiWoong Kim [Thu, 10 Apr 2014 10:14:31 +0000 (19:14 +0900)]
touchscreen: set touchscreen resolution
Change-Id: I0eaf5d48cd3caa958fd89ef53e77f877bd9761d0
Signed-off-by: GiWoong Kim <giwoong.kim@samsung.com>
Casey Schaufler [Tue, 28 Jan 2014 19:31:46 +0000 (11:31 -0800)]
smack: fix: allow either entry be missing on access/access2 check (v2)
commit
398ce073700a2a3e86b5a0b1edecdddfa3996b27
Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date: Thu Nov 28 19:16:46 2013 +0200
smack: fix: allow either entry be missing on access/access2 check (v2)
This is a regression caused by
f7112e6c. When either subject or
object is not found the answer for access should be no. This
patch fixes the situation. '0' is written back instead of failing
with -EINVAL.
v2: cosmetic style fixes
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Change-Id: Ibb84d8ab1e70d5f6689705ed28b0946b9ddde21d
Signed-off-by: Casey Schaufler <casey.schaufler@intel.com>
Casey Schaufler [Tue, 24 Dec 2013 16:41:54 +0000 (08:41 -0800)]
Smack: Make the syslog control configurable
commit
00f84f3f2e9d088f06722f4351d67f5f577abe22
Author: Casey Schaufler <casey@schaufler-ca.com>
Date: Mon Dec 23 11:07:10 2013 -0800
The syslog control requires that the calling proccess
have the floor ("_") Smack label. Tizen does not run any
processes except for kernel helpers with the floor label.
This changes allows the admin to configure a specific
label for syslog. The default value is the star ("*")
label, effectively removing the restriction. The value
can be set using smackfs/syslog for anyone who wants
a more restrictive behavior.
Change-Id: Iec4c42c4d156fe29915f07a6f40d6c58ad894d6a
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Casey Schaufler [Thu, 21 Nov 2013 08:55:10 +0000 (10:55 +0200)]
Smack: Cgroup filesystem access
The cgroup filesystems are not mounted using conventional
mechanisms. This prevents the use of mount options to
set Smack attributes. This patch makes the behavior
of cgroup filesystems compatable with the way systemd
uses them.
Change-Id: I1e0429f133db9e14117dc754d682dec08221354c
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Casey Schaufler [Tue, 22 Oct 2013 18:47:45 +0000 (11:47 -0700)]
Smack: Ptrace access check mode
When the ptrace security hooks were split the addition of
a mode parameter was not taken advantage of in the Smack
ptrace access check. This changes the access check from
always looking for read and write access to using the
passed mode. This will make use of /proc much happier.
Targeted for git://git.gitorious.org/smack-next/kernel.git
Change-Id: I59f9f5fb88da2dd08f80a2946afb211db103b16e
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Casey Schaufler [Sat, 12 Oct 2013 01:06:39 +0000 (18:06 -0700)]
Smack: Implement lock security mode
Linux file locking does not follow the same rules
as other mechanisms. Even though it is a write operation
a process can set a read lock on files which it has open
only for read access. Two programs with read access to
a file can use read locks to communicate.
This is not acceptable in a Mandatory Access Control
environment. Smack treats setting a read lock as the
write operation that it is. Unfortunately, many programs
assume that setting a read lock is a read operation.
These programs are unhappy in the Smack environment.
This patch introduces a new access mode (lock) to address
this problem. A process with lock access to a file can
set a read lock. A process with write access to a file can
set a read lock or a write lock. This prevents a situation
where processes are granted write access just so they can
set read locks.
Targeted for git://git.gitorious.org/smack-next/kernel.git
Change-Id: Ia9024f37a5ce51eddbb19053b800f4d70948ef17
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Jinhyung Choi [Wed, 9 Apr 2014 07:47:59 +0000 (16:47 +0900)]
driver: added sensor and jack driver
Maru power supply device driver is added, but it is not built.
It will be fixed.
Change-Id: Ib4a10e9c4434d272c445f8551ef9cb74b89b963f
Signed-off-by: Jinhyung Choi <jinhyung2.choi@samsung.com>
jinhyung.jo [Thu, 10 Apr 2014 08:10:24 +0000 (17:10 +0900)]
maru : Enable overlay driver
Fix the problem that video_device is being registered
without v4l2_device.
Change-Id: I5a17c741f9e8796777d9d5feb9261c4a7de9f350
Signed-off-by: Jinhyung Jo <jinhyung.jo@samsung.com>
Max Yu [Thu, 10 Apr 2014 02:21:29 +0000 (19:21 -0700)]
Merge "enable Tizen IVI required kernel options" into tizen_linux_3.12
Stanislav Vorobiov [Thu, 3 Apr 2014 05:57:00 +0000 (09:57 +0400)]
enable Tizen IVI required kernel options
For details see
https://wiki.tizen.org/wiki/IVI/artem-kernel#Kernel_configuration
Change-Id: I49432ab6a3d66408de197e8b420ebdd915dc2527
Signed-off-by: Stanislav Vorobiov <s.vorobiov@samsung.com>
SeokYeon Hwang [Wed, 9 Apr 2014 07:59:57 +0000 (00:59 -0700)]
Merge "brillcodec: remove the first memory block reserved for meta buffer." into tizen_linux_3.12
SeokYeon Hwang [Wed, 9 Apr 2014 07:59:45 +0000 (00:59 -0700)]
Merge "brillcodec: improve an exception case when requested memory size is invalid." into tizen_linux_3.12
SeokYeon Hwang [Wed, 9 Apr 2014 05:54:38 +0000 (14:54 +0900)]
Merge branch 'tizen_linux_3.12' into tizen_linux_3.12
Change-Id: I3ea847950cfe2991c980ebb317932a348922af16
SeokYeon Hwang [Wed, 9 Apr 2014 05:30:35 +0000 (14:30 +0900)]
Using initramfs for v86d.
Change-Id: I299da86a1239b6add1befa39c92d20ba4be07069
Signed-off-by: SeokYeon Hwang <syeon.hwang@samsung.com>
Stanislav Vorobiov [Tue, 8 Apr 2014 06:31:57 +0000 (10:31 +0400)]
Revert "enable Tizen IVI required kernel options"
This reverts commit
f7090f807e725b4fa5ba32a4f3bb1c2a86ad5e0d.
Change-Id: I469dc544d6e410025d97d6e7b4dba90fce478e1d
Signed-off-by: Stanislav Vorobiov <s.vorobiov@samsung.com>
Stanislav Vorobiov [Tue, 8 Apr 2014 06:31:07 +0000 (10:31 +0400)]
separate kernel config for Tizen IVI
Change-Id: I5a66b394d3065d138605bad9727079c8a50f79cc
Signed-off-by: Stanislav Vorobiov <s.vorobiov@samsung.com>
Stanislav Vorobiov [Thu, 3 Apr 2014 05:57:00 +0000 (09:57 +0400)]
enable Tizen IVI required kernel options
For details see
https://wiki.tizen.org/wiki/IVI/artem-kernel#Kernel_configuration
Change-Id: Iaac79f8ae9ea0758666f7cf39cc98c7736026d5d
Signed-off-by: Stanislav Vorobiov <s.vorobiov@samsung.com>
Stanislav Vorobiov [Fri, 21 Mar 2014 06:28:40 +0000 (10:28 +0400)]
maru: disable overlay driver
Overlay driver currently fails to
load because video_device is being registered
without v4l2_device, so disable it for now
Change-Id: Idbec8e41c3a79fc30ffd8bf30d6c2fb52443baad
Signed-off-by: Stanislav Vorobiov <s.vorobiov@samsung.com>
jinhyung.jo [Mon, 17 Mar 2014 05:59:46 +0000 (14:59 +0900)]
VirtGL : Add a GL passthrough device for Tizen emulator
Add a GL passthrough device for Tizen Emulator
Change-Id: I53d455ebf433a5c648951a2e13406e2ac4470712
Signed-off-by: Jinhyung Jo <jinhyung.jo@samsung.com>
jinhyung.jo [Mon, 17 Mar 2014 05:51:21 +0000 (14:51 +0900)]
maru_fb : Add a framebuffer device for Tizen emulator
Add a framebuffer device for Tizen emulator
Change-Id: I2090366287fb7769bae28286a6b21384ad233d4b
Signed-off-by: Jinhyung Jo <jinhyung.jo@samsung.com>
Stanislav Vorobiov [Mon, 17 Mar 2014 09:52:24 +0000 (13:52 +0400)]
emulator config updated
Change-Id: I6399d61b301782864e404e30b45b8feab089e147
Stanislav Vorobiov [Fri, 14 Mar 2014 13:45:37 +0000 (17:45 +0400)]
VIGS: Fixed for kernel 3.12
Change-Id: Ic4ae0c0dea0e9901c5f648e1b215fd82d26cc3b2
Stanislav Vorobiov [Mon, 17 Mar 2014 07:59:10 +0000 (11:59 +0400)]
slp_global_lock: Fixed for kernel 3.12
Change-Id: I89f0cedba73eae66e56911b8ebcfb9010443d4bd
Stanislav Vorobiov [Fri, 14 Mar 2014 11:57:02 +0000 (15:57 +0400)]
YaGL: Fixed for kernel 3.12
Change-Id: I59a6d69d7bbdfd27e046372974f7651cf52aa5fb
Stanislav Vorobiov [Thu, 6 Mar 2014 13:48:33 +0000 (17:48 +0400)]
YaGL/VIGS: Version bump
GLESv3 merge version bump
Change-Id: I34813deb38a2c6334a2c04cb55dfd478c2041e8a
Stanislav Vorobiov [Tue, 18 Feb 2014 13:05:46 +0000 (17:05 +0400)]
VIGS: Support plane z-pos setting from user-space
Change-Id: I72a60beac3dc23f23517f310d5bee59c6833b748
Stanislav Vorobiov [Mon, 10 Feb 2014 16:59:01 +0000 (20:59 +0400)]
VIGS: Implemented plane support
We now support up to 2 hardware planes
with z-ordering and scaling. This patch also
adds surface scanout flag support. Surface scanout
flag is used as a hint that helps the host to decide
how to process the surface - either upload it to texture
or continously scanout data out of surface's VRAM
Change-Id: I76f88579929efd14ea81e67d2f7a231a7dee4e9d
Stanislav Vorobiov [Thu, 20 Feb 2014 07:51:51 +0000 (11:51 +0400)]
VIGS: Fix fence ack losses
It's incorrect to have vblank enable/disable flag
in INT register, it can cause fence ack losses, consider
the following scenario:
1. Fence interrupt is set on host, fence_pending bit is
set in INT register
2. vblank is turned off on guest, INT register is being
written to and since fence_pending bit is 1 it's
CLEARED on host
3. Now guest handles fence IRQ, but fence_pending bit
is 0, thus, fence ack is lost
The solution is to have separate register - CON and
vblank enable/disable bit should be there
Change-Id: Ieb3f1a0bd1722fa05fd4e7ca425079fb8799e533
Stanislav Vorobiov [Tue, 22 Oct 2013 10:15:56 +0000 (14:15 +0400)]
YaGL: Support host OpenGL version report
Change-Id: Ifaf7abb86f7f0a650ab6954be23ae95233261450
Stanislav Vorobiov [Thu, 28 Nov 2013 10:51:12 +0000 (14:51 +0400)]
YaGL: Implemented multicore rendering and fences
We now use multicore rendering, i.e. we offload all
rendering to a separate thread and use fences to wait
until certain parts of it are complete. This patch
implements fences via TTM sync objects, it also uses
TTM execbuffer utils to fence buffers and TTM object
files to export fences to user space
Change-Id: Ibed86c3161f3b7207725c8662ffa909d103acedf
Stanislav Vorobiov [Wed, 11 Dec 2013 09:26:13 +0000 (13:26 +0400)]
VIGS: Don't rely on 'no_wait_reserve' parameter when pinnin GEMs
'no_wait_reserve' parameter isn't accounted for in
ttm_bo_validate, so don't rely on GEM reserve wait,
just retry things instead
Change-Id: Iab57645c8ab96f30c01b943342cdff9bacac8feb
Stanislav Vorobiov [Tue, 10 Dec 2013 16:52:54 +0000 (20:52 +0400)]
VIGS: Fix pageflip race
Must use event_lock, since it's being used
in vigs_finish_pageflips to lock pageflip_event_list.
Also, by the time we call drm_vblank_put the event might already
be processed, so check for that
Change-Id: I9c5de98452353c6d4f09e4e4fbd92176cfd8ee40
Stanislav Vorobiov [Mon, 7 Oct 2013 11:31:29 +0000 (15:31 +0400)]
YaGL: Version bump
Change-Id: I6ecf4d3e2121cacc293af82bfde8d96bfe55dc06
Stanislav Vorobiov [Tue, 24 Sep 2013 14:48:33 +0000 (18:48 +0400)]
YaGL: Transport improved
The improvements are:
* No more mlock/munlock. We now have ioctls for locking drawable
memory so that compile transfers could be created on host. This
is only used by offscreen backend though
* We're now using a single buffer for marshalling instead of two: one
for commands and one for data. Also, the buffer can now be of any
size up to 2M, it's implemented as a page list, thus, we don't need
to allocate contigous memory anymore
Change-Id: Ia9b716c9135df75535dc515367550c9fbcf9c737
Stanislav Vorobiov [Fri, 2 Aug 2013 13:54:12 +0000 (17:54 +0400)]
VIGS: Don't 'update_vram' on 'set_root_surface'
This is now automatically happens on glFinish,
eglSwapBuffers, eglCopyBuffers, etc.
Change-Id: Ie20724ec8ce6283e8fda1248f368f00e704e0e3d
Stanislav Vorobiov [Wed, 31 Jul 2013 10:32:28 +0000 (14:32 +0400)]
YaGL: Version bump
Change-Id: Ie681f7251648451d9a425e97f215a8b0b50ebbbb
Stanislav Vorobiov [Wed, 24 Jul 2013 07:24:08 +0000 (11:24 +0400)]
VIGS: Use BO instead of VMA in struct vigs_mman_vma
It's better to use BO in struct vigs_mman_vma instead of
VMA that was allocated in mmap call
Change-Id: I883613c71bf3880dba9edb6fdaa7fd0aee83d044
Stanislav Vorobiov [Tue, 23 Jul 2013 15:40:03 +0000 (19:40 +0400)]
VIGS: Delay surface destruction
We should destroy surfaces on TTM BO destruction
instead of GEM free handler. The latter may cause races
like this:
1. GEM is created
2. GEM is mapped and written to
3. GEM is freed, but not unmapped. Thus, the host gets
a "destroy_surface" command and target frees up
an id from IDR.
4. Another GEM is created. Thus, it's assigned a freed id, which
is id of first GEM, the host gets "create_surface" command
5. First GEM is unmapped, host gets "update_gpu" command with
wrong data and size and crashes
The race occured on wayland/GBM during window resize
Change-Id: Ifddab147999e450e4b4affd7144d91f29fb39534
Stanislav Vorobiov [Fri, 19 Jul 2013 16:35:30 +0000 (20:35 +0400)]
VIGS: Don't call TTM's vm_close
TTM's vm_close sets vm_private_data to NULL even if VMA is
still referenced, we don't want this since this may cause
a NULL pointer dereference. And this indeed happens sometimes
on wayland
Change-Id: Idf4af80ef0d472a1a480491cb56e6cc8d9d39123
Stanislav Vorobiov [Fri, 12 Jul 2013 12:15:38 +0000 (16:15 +0400)]
VIGS: Fixed vigs_fb_create return values
Change-Id: Ice57af4d21899080c5572343f5734697cd20e21d
VIGS: Added dummy cursor handling
Stanislav Vorobiov [Thu, 11 Jul 2013 09:23:18 +0000 (13:23 +0400)]
VIGS: Lock console before fb notifier chain walk
This is required to work properly with fbcon
Change-Id: I641e2762e7918cd9d9147f3a44ba2911a1f50019
Stanislav Vorobiov [Thu, 11 Jul 2013 06:43:20 +0000 (10:43 +0400)]
VIGS: Make GEM access tracking optional
For dumb GEM API we need to have GEM access tracking
disabled and always assume that access is RW.
Thus, we make GEM access tracking optional, so that user-mode
can specify if it's wanted or not
Change-Id: Ia8be76e1c15b0b4734997c16ad245b018c6d2ba6
Stanislav Vorobiov [Tue, 2 Jul 2013 14:51:23 +0000 (18:51 +0400)]
VIGS: GEM access tracking implemented
In order to minimize GEM data transfers between
target and host we now track GEM memory accesses for each
VMA. Thus, we only update VRAM/GPU when there's at least one
VMA that requires it
Change-Id: Ib65ff22957e6a89d83329deca4753b69cd39ca3d