<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v3.14.75</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.14.75</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.14.75'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2016-08-10T08:21:13Z</updated>
<entry>
<title>Linux 3.14.75</title>
<updated>2016-08-10T08:21:13Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2016-08-10T08:21:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b8b6a72089869dee41bd9f29e86bbcf6501e5524'/>
<id>urn:sha1:b8b6a72089869dee41bd9f29e86bbcf6501e5524</id>
<content type='text'>
</content>
</entry>
<entry>
<title>net: mvneta: set real interrupt per packet for tx_done</title>
<updated>2016-08-10T08:21:04Z</updated>
<author>
<name>Dmitri Epshtein</name>
<email>dima@marvell.com</email>
</author>
<published>2016-07-06T02:18:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=05abf74f864b6d8c38b34d5314e0f50910105584'/>
<id>urn:sha1:05abf74f864b6d8c38b34d5314e0f50910105584</id>
<content type='text'>
commit 06708f81528725148473c0869d6af5f809c6824b upstream.

Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
set coalescing threshold to a value guaranteeing interrupt generation
per each sent packet, so that buffers can be released with no delay.

In fact setting threshold to '1' was wrong, because it causes interrupt
every two packets. According to the documentation a reason behind it is
following - interrupt occurs once sent buffers counter reaches a value,
which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
behavior was confirmed during tests. Also when testing the SoC working
as a NAS device, better performance was observed with int-per-packet,
as it strongly depends on the fact that all transmitted packets are
released immediately.

This commit enables NETA controller work in interrupt per sent packet mode
by setting coalescing threshold to 0.

Signed-off-by: Dmitri Epshtein &lt;dima@marvell.com&gt;
Signed-off-by: Marcin Wojtas &lt;mw@semihalf.com&gt;
Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
Acked-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libceph: apply new_state before new_up_client on incrementals</title>
<updated>2016-08-10T08:21:04Z</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2016-07-19T01:50:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6b96b2d473701b45df3fea8dd9796b6ec39e6d54'/>
<id>urn:sha1:6b96b2d473701b45df3fea8dd9796b6ec39e6d54</id>
<content type='text'>
commit 930c532869774ebf8af9efe9484c597f896a7d46 upstream.

Currently, osd_weight and osd_state fields are updated in the encoding
order.  This is wrong, because an incremental map may look like e.g.

    new_up_client: { osd=6, addr=... } # set osd_state and addr
    new_state: { osd=6, xorstate=EXISTS } # clear osd_state

Suppose osd6's current osd_state is EXISTS (i.e. osd6 is down).  After
applying new_up_client, osd_state is changed to EXISTS | UP.  Carrying
on with the new_state update, we flip EXISTS and leave osd6 in a weird
"!EXISTS but UP" state.  A non-existent OSD is considered down by the
mapping code

2087    for (i = 0; i &lt; pg-&gt;pg_temp.len; i++) {
2088            if (ceph_osd_is_down(osdmap, pg-&gt;pg_temp.osds[i])) {
2089                    if (ceph_can_shift_osds(pi))
2090                            continue;
2091
2092                    temp-&gt;osds[temp-&gt;size++] = CRUSH_ITEM_NONE;

and so requests get directed to the second OSD in the set instead of
the first, resulting in OSD-side errors like:

[WRN] : client.4239 192.168.122.21:0/2444980242 misdirected client.4239.1:2827 pg 2.5df899f2 to osd.4 not [1,4,6] in e680/680

and hung rbds on the client:

[  493.566367] rbd: rbd0: write 400000 at 11cc00000 (0)
[  493.566805] rbd: rbd0:   result -6 xferred 400000
[  493.567011] blk_update_request: I/O error, dev rbd0, sector 9330688

The fix is to decouple application from the decoding and:
- apply new_weight first
- apply new_state before new_up_client
- twiddle osd_state flags if marking in
- clear out some of the state if osd is destroyed

Fixes: http://tracker.ceph.com/issues/14901

Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Reviewed-by: Josh Durgin &lt;jdurgin@redhat.com&gt;
[idryomov@gmail.com: backport to 3.10-3.14: strip primary-affinity]
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipr: Clear interrupt on croc/crocodile when running with LSI</title>
<updated>2016-08-10T08:21:03Z</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2016-06-27T14:09:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a3e8780243019b958037cbb7c9f5903fbea9684b'/>
<id>urn:sha1:a3e8780243019b958037cbb7c9f5903fbea9684b</id>
<content type='text'>
commit 54e430bbd490e18ab116afa4cd90dcc45787b3df upstream.

If we fall back to using LSI on the Croc or Crocodile chip we need to
clear the interrupt so we don't hang the system.

Tested-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: fix oops caused by wrong rtnl dellink usage</title>
<updated>2016-08-10T08:21:03Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-06-21T13:45:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=aaf95b87cc9d2836a6103f4628d71186411033aa'/>
<id>urn:sha1:aaf95b87cc9d2836a6103f4628d71186411033aa</id>
<content type='text'>
commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 upstream.

For 'real' hardware CAN devices the netlink interface is used to set CAN
specific communication parameters. Real CAN hardware can not be created nor
removed with the ip tool ...

This patch adds a private dellink function for the CAN device driver interface
that does just nothing.

It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl
newlink usage") but for dellink.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: fix handling of unmodifiable configuration options fix</title>
<updated>2016-08-10T08:21:03Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-06-21T10:14:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6f8f768a3586b6fbd50e249e7fe4f964a6994685'/>
<id>urn:sha1:6f8f768a3586b6fbd50e249e7fe4f964a6994685</id>
<content type='text'>
commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.

With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable
configuration options) a new can_validate() function was introduced.

When invoking 'ip link set can0 type can' without any configuration data
can_validate() tries to validate the content without taking into account that
there's totally no content. This patch adds a check for missing content.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: at91_can: RX queue could get stuck at high bus load</title>
<updated>2016-08-10T08:21:03Z</updated>
<author>
<name>Wolfgang Grandegger</name>
<email>wg@grandegger.com</email>
</author>
<published>2016-06-13T13:44:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5c3a7aac3d8dc9baa708c7ce37df2dbae3098d1d'/>
<id>urn:sha1:5c3a7aac3d8dc9baa708c7ce37df2dbae3098d1d</id>
<content type='text'>
commit 43200a4480cbbe660309621817f54cbb93907108 upstream.

At high bus load it could happen that "at91_poll()" enters with all RX
message boxes filled up. If then at the end the "quota" is exceeded as
well, "rx_next" will not be reset to the first RX mailbox and hence the
interrupts remain disabled.

Signed-off-by: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Tested-by: Amr Bekhit &lt;amrbekhit@gmail.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: block: fix packed command header endianness</title>
<updated>2016-08-10T08:21:03Z</updated>
<author>
<name>Taras Kondratiuk</name>
<email>takondra@cisco.com</email>
</author>
<published>2016-07-13T22:05:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2ac56bef9b9bf169da254fc1a7d5f7dbf30adc3f'/>
<id>urn:sha1:2ac56bef9b9bf169da254fc1a7d5f7dbf30adc3f</id>
<content type='text'>
commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 upstream.

The code that fills packed command header assumes that CPU runs in
little-endian mode. Hence the header is malformed in big-endian mode
and causes MMC data transfer errors:

[  563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[  563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1

Convert header data to LE.

Signed-off-by: Taras Kondratiuk &lt;takondra@cisco.com&gt;
Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>qeth: delete napi struct when removing a qeth device</title>
<updated>2016-08-10T08:21:03Z</updated>
<author>
<name>Ursula Braun</name>
<email>ubraun@linux.vnet.ibm.com</email>
</author>
<published>2016-07-04T12:07:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f6aabfad833531e1bbb6e095393e2de27f6e990a'/>
<id>urn:sha1:f6aabfad833531e1bbb6e095393e2de27f6e990a</id>
<content type='text'>
commit 7831b4ff0d926e0deeaabef9db8800ed069a2757 upstream.

A qeth_card contains a napi_struct linked to the net_device during
device probing. This struct must be deleted when removing the qeth
device, otherwise Panic on oops can occur when qeth devices are
repeatedly removed and added.

Fixes: a1c3ed4c9ca ("qeth: NAPI support for l2 and l3 discipline")
Signed-off-by: Ursula Braun &lt;ubraun@linux.vnet.ibm.com&gt;
Tested-by: Alexander Klein &lt;ALKL@de.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: verify extent header depth</title>
<updated>2016-08-10T08:21:03Z</updated>
<author>
<name>Vegard Nossum</name>
<email>vegard.nossum@oracle.com</email>
</author>
<published>2016-07-15T04:22:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e6fa962341c8d198dd59a0ff0e5b89deb87478d7'/>
<id>urn:sha1:e6fa962341c8d198dd59a0ff0e5b89deb87478d7</id>
<content type='text'>
commit 7bc9491645118c9461bd21099c31755ff6783593 upstream.

Although the extent tree depth of 5 should enough be for the worst
case of 2*32 extents of length 1, the extent tree code does not
currently to merge nodes which are less than half-full with a sibling
node, or to shrink the tree depth if possible.  So it's possible, at
least in theory, for the tree depth to be greater than 5.  However,
even in the worst case, a tree depth of 32 is highly unlikely, and if
the file system is maliciously corrupted, an insanely large eh_depth
can cause memory allocation failures that will trigger kernel warnings
(here, eh_depth = 65280):

    JBD2: ext4.exe wants too many credits credits:195849 rsv_credits:0 max:256
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 50 at fs/jbd2/transaction.c:293 start_this_handle+0x569/0x580
    CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ #508
    Stack:
     604a8947 625badd8 0002fd09 00000000
     60078643 00000000 62623910 601bf9bc
     62623970 6002fc84 626239b0 900000125
    Call Trace:
     [&lt;6001c2dc&gt;] show_stack+0xdc/0x1a0
     [&lt;601bf9bc&gt;] dump_stack+0x2a/0x2e
     [&lt;6002fc84&gt;] __warn+0x114/0x140
     [&lt;6002fdff&gt;] warn_slowpath_null+0x1f/0x30
     [&lt;60165829&gt;] start_this_handle+0x569/0x580
     [&lt;60165d4e&gt;] jbd2__journal_start+0x11e/0x220
     [&lt;60146690&gt;] __ext4_journal_start_sb+0x60/0xa0
     [&lt;60120a81&gt;] ext4_truncate+0x131/0x3a0
     [&lt;60123677&gt;] ext4_setattr+0x757/0x840
     [&lt;600d5d0f&gt;] notify_change+0x16f/0x2a0
     [&lt;600b2b16&gt;] do_truncate+0x76/0xc0
     [&lt;600c3e56&gt;] path_openat+0x806/0x1300
     [&lt;600c55c9&gt;] do_filp_open+0x89/0xf0
     [&lt;600b4074&gt;] do_sys_open+0x134/0x1e0
     [&lt;600b4140&gt;] SyS_open+0x20/0x30
     [&lt;6001ea68&gt;] handle_syscall+0x88/0x90
     [&lt;600295fd&gt;] userspace+0x3fd/0x500
     [&lt;6001ac55&gt;] fork_handler+0x85/0x90

    ---[ end trace 08b0b88b6387a244 ]---

[ Commit message modified and the extent tree depath check changed
from 5 to 32 -- tytso ]

Cc: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
