<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v4.10.1</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.10.1</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.10.1'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-02-26T10:09:33Z</updated>
<entry>
<title>Linux 4.10.1</title>
<updated>2017-02-26T10:09:33Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2017-02-26T10:09:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d23a9821d3972ae373357e933c8af8216d72e374'/>
<id>urn:sha1:d23a9821d3972ae373357e933c8af8216d72e374</id>
<content type='text'>
</content>
</entry>
<entry>
<title>xfs: clear delalloc and cache on buffered write failure</title>
<updated>2017-02-26T10:09:19Z</updated>
<author>
<name>Brian Foster</name>
<email>bfoster@redhat.com</email>
</author>
<published>2017-02-17T01:19:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=289ab6e9b7ce3ba8a31a95805ffc64024e8a7007'/>
<id>urn:sha1:289ab6e9b7ce3ba8a31a95805ffc64024e8a7007</id>
<content type='text'>
commit fa7f138ac4c70dc00519c124cf7cd4862a0a5b0e upstream.

The buffered write failure handling code in
xfs_file_iomap_end_delalloc() has a couple minor problems. First, if
written == 0, start_fsb is not rounded down and it fails to kill off a
delalloc block if the start offset is block unaligned. This results in a
lingering delalloc block and broken delalloc block accounting detected
at unmount time. Fix this by rounding down start_fsb in the unlikely
event that written == 0.

Second, it is possible for a failed overwrite of a delalloc extent to
leave dirty pagecache around over a hole in the file. This is because is
possible to hit -&gt;iomap_end() on write failure before the iomap code has
attempted to allocate pagecache, and thus has no need to clean it up. If
the targeted delalloc extent was successfully written by a previous
write, however, then it does still have dirty pages when -&gt;iomap_end()
punches out the underlying blocks. This ultimately results in writeback
over a hole. To fix this problem, unconditionally punch out the
pagecache from XFS before the associated delalloc range.

Signed-off-by: Brian Foster &lt;bfoster@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down</title>
<updated>2017-02-26T10:09:19Z</updated>
<author>
<name>Michael Schenk</name>
<email>michael.schenk@albis-elcon.com</email>
</author>
<published>2017-01-26T17:25:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c1f105b5dc83297e966552976b10f9f6239359c6'/>
<id>urn:sha1:c1f105b5dc83297e966552976b10f9f6239359c6</id>
<content type='text'>
commit 575ddce0507789bf9830d089557d2199d2f91865 upstream.

In the function rtl_usb_start we pre-allocate a certain number of urbs
for RX path but they will not be freed when calling rtl_usb_stop. This
results in leaking urbs when doing ifconfig up and down. Eventually,
the system has no available urbs.

Signed-off-by: Michael Schenk &lt;michael.schenk@albis-elcon.com&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>block: fix double-free in the failure path of cgwb_bdi_init()</title>
<updated>2017-02-26T10:09:19Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2017-02-08T20:19:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=dea972f381a12fa0f4026a6eb6070a4fe6fb0465'/>
<id>urn:sha1:dea972f381a12fa0f4026a6eb6070a4fe6fb0465</id>
<content type='text'>
commit 5f478e4ea5c5560b4e40eb136991a09f9389f331 upstream.

When !CONFIG_CGROUP_WRITEBACK, bdi has single bdi_writeback_congested
at bdi-&gt;wb_congested.  cgwb_bdi_init() allocates it with kzalloc() and
doesn't do further initialization.  This usually works fine as the
reference count gets bumped to 1 by wb_init() and the put from
wb_exit() releases it.

However, when wb_init() fails, it puts the wb base ref automatically
freeing the wb and the explicit kfree() in cgwb_bdi_init() error path
ends up trying to free the same pointer the second time causing a
double-free.

Fix it by explicitly initilizing the refcnt to 1 and putting the base
ref from cgwb_bdi_destroy().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Fixes: a13f35e87140 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback")
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ACPICA: Linuxize: Restore and fix Intel compiler build</title>
<updated>2017-02-26T10:09:19Z</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2017-02-08T03:00:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=96081d826cb3ef1c911e49a3f84cc24ded9bcbf2'/>
<id>urn:sha1:96081d826cb3ef1c911e49a3f84cc24ded9bcbf2</id>
<content type='text'>
commit ffab9188e444854882dbc291500d576d6bad7b7b upstream.

ACPICA commit b59347d0b8b676cb555fe8da5cad08fcd4eeb0d3

The following commit cleans up compiler specific inclusions:

  Commit: 9fa1cebdbfff3db8953cebca8ee327d75edefc40
  Subject: ACPICA: OSL: Cleanup the inclusion order of the compiler-specific headers

But breaks one thing due to the following old issue:

 Buidling Linux kernel with Intel compiler originally depends on acgcc.h
 not acintel.h.

So after making Intel compiler build working in ACPICA upstream by
correctly using acintel.h, it becomes unable to build Linux kernel using
Intel compiler as there is no acintel.h in the kernel source tree.

This patch releases acintel.h to Linux kernel and fixes its inclusion in
acenv.h.

Fixes: 9fa1cebdbfff (ACPICA: OSL: Cleanup the inclusion order of the compiler-specific headers)
Link: https://github.com/acpica/acpica/commit/b59347d0
Tested-by: Stepan M Mishura &lt;stepan.m.mishura@intel.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>netfilter: nf_ct_helper: warn when not applying default helper assignment</title>
<updated>2017-02-26T10:09:19Z</updated>
<author>
<name>Jiri Kosina</name>
<email>jkosina@suse.cz</email>
</author>
<published>2017-02-01T20:01:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8ab75da134c11f0184144de469d16fd7eea9f445'/>
<id>urn:sha1:8ab75da134c11f0184144de469d16fd7eea9f445</id>
<content type='text'>
commit dfe75ff8ca74f54b0fa5a326a1aa9afa485ed802 upstream.

Commit 3bb398d925 ("netfilter: nf_ct_helper: disable automatic helper
assignment") is causing behavior regressions in firewalls, as traffic
handled by conntrack helpers is now by default not passed through even
though it was before due to missing CT targets (which were not necessary
before this commit).

The default had to be switched off due to security reasons [1] [2] and
therefore should stay the way it is, but let's be friendly to firewall
admins and issue a warning the first time we're in situation where packet
would be likely passed through with the old default but we're likely going
to drop it on the floor now.

Rewrite the code a little bit as suggested by Linus, so that we avoid
spaghettiing the code even more -- namely the whole decision making
process regarding helper selection (either automatic or not) is being
separated, so that the whole logic can be simplified and code (condition)
duplication reduced.

[1] https://cansecwest.com/csw12/conntrack-attack.pdf
[2] https://home.regit.org/netfilter-en/secure-use-of-helpers/

Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>goldfish: Sanitize the broken interrupt handler</title>
<updated>2017-02-26T10:09:19Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2017-02-15T10:11:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=910c3e4d118d6e833e5bf4fa863f108db4c398fb'/>
<id>urn:sha1:910c3e4d118d6e833e5bf4fa863f108db4c398fb</id>
<content type='text'>
commit 6cf18e6927c0b224f972e3042fb85770d63cb9f8 upstream.

This interrupt handler is broken in several ways:

  - It loops forever when the op code is not decodeable

  - It never returns IRQ_HANDLED because the only way to exit the loop
    returns IRQ_NONE unconditionally.

The whole concept of this is broken. Creating devices in an interrupt
handler is beyond any point of sanity.

Make it at least behave halfways sane so accidental users do not have to
deal with a hard to debug lockup.

Fixes: e809c22b8fb028 ("goldfish: add the goldfish virtual bus")
Reported-by: Gabriel C &lt;nix.or.die@gmail.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86/platform/goldfish: Prevent unconditional loading</title>
<updated>2017-02-26T10:09:19Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2017-02-15T10:11:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=adf7f1350a0c6774c8b09e0c31058f4ce638aa57'/>
<id>urn:sha1:adf7f1350a0c6774c8b09e0c31058f4ce638aa57</id>
<content type='text'>
commit 47512cfd0d7a8bd6ab71d01cd89fca19eb2093eb upstream.

The goldfish platform code registers the platform device unconditionally
which causes havoc in several ways if the goldfish_pdev_bus driver is
enabled:

 - Access to the hardcoded physical memory region, which is either not
   available or contains stuff which is completely unrelated.

 - Prevents that the interrupt of the serial port can be requested

 - In case of a spurious interrupt it goes into a infinite loop in the
   interrupt handler of the pdev_bus driver (which needs to be fixed
   seperately).

Add a 'goldfish' command line option to make the registration opt-in when
the platform is compiled in.

I'm seriously grumpy about this engineering trainwreck, which has seven
SOBs from Intel developers for 50 lines of code. And none of them figured
out that this is broken. Impressive fail!

Fixes: ddd70cf93d78 ("goldfish: platform device for x86")
Reported-by: Gabriel C &lt;nix.or.die@gmail.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: serial: console: fix uninitialised spinlock</title>
<updated>2017-02-26T10:09:18Z</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-02-08T17:53:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=33b11454af5dd7b4eee9b833fc0223d389e48aa8'/>
<id>urn:sha1:33b11454af5dd7b4eee9b833fc0223d389e48aa8</id>
<content type='text'>
commit 14816b16fa0adac24f82492f18fa62c55acabbbe upstream.

Since commit 4a510969374a ("tty: Make tty_files_lock per-tty") a new
tty_struct spin lock is taken in the tty release path, but the
USB-serial-console hack was never updated hence leaving the lock of its
"fake" tty uninitialised. This was eventually detected by lockdep.

Make sure to initialise the new lock also for the fake tty to address
this regression.

Yes, this code is a mess, but cleaning it up is left for another day.

Fixes: 4a510969374a ("tty: Make tty_files_lock per-tty")
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: serial: ark3116: fix register-accessor error handling</title>
<updated>2017-02-26T10:09:18Z</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2017-01-12T13:56:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=122b5f43f6eae38da8b3b58f6cc2b2f60e325b5c'/>
<id>urn:sha1:122b5f43f6eae38da8b3b58f6cc2b2f60e325b5c</id>
<content type='text'>
commit 9fef37d7cf170522fb354d6d0ea6de09b9b16678 upstream.

The current implementation failed to detect short transfers, something
which could lead to bits of the uninitialised heap transfer buffer
leaking to user space.

Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.")
Fixes: f4c1e8d597d1 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.")
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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