<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include, branch v3.15.6</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.15.6</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.15.6'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2014-07-17T23:23:19Z</updated>
<entry>
<title>kernfs: introduce kernfs_pin_sb()</title>
<updated>2014-07-17T23:23:19Z</updated>
<author>
<name>Li Zefan</name>
<email>lizefan@huawei.com</email>
</author>
<published>2014-06-30T03:50:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f5fc1ec5e8d32bfb559a87800633b0a82a37e640'/>
<id>urn:sha1:f5fc1ec5e8d32bfb559a87800633b0a82a37e640</id>
<content type='text'>
commit 4e26445faad366d67d7723622bf6a60a6f0f5993 upstream.

kernfs_pin_sb() tries to get a refcnt of the superblock.

This will be used by cgroupfs.

v2:
- make kernfs_pin_sb() return the superblock.
- drop kernfs_drop_sb().

tj: Updated the comment a bit.

[ This is a prerequisite for a bugfix. ]
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Li Zefan &lt;lizefan@huawei.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>kernfs: implement kernfs_root-&gt;supers list</title>
<updated>2014-07-17T23:23:19Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-04-09T15:07:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0b2332fbef1df5db5ed85fb1812aca9d50aa6415'/>
<id>urn:sha1:0b2332fbef1df5db5ed85fb1812aca9d50aa6415</id>
<content type='text'>
commit 7d568a8383bbb9c1f5167781075906acb2bb1550 upstream.

Currently, there's no way to find out which super_blocks are
associated with a given kernfs_root.  Let's implement it - the planned
inotify extension to kernfs_notify() needs it.

Make kernfs_super_info point back to the super_block and chain it at
kernfs_root-&gt;supers.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
[lizf: Backported to 3.15: Adjust context]
Signed-off-by: Li Zefan &lt;lizefan@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ring-buffer: Check if buffer exists before polling</title>
<updated>2014-07-17T23:23:18Z</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2014-06-10T13:46:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ae2fbe4ff3f3368325629d884fe0d53f23d8f8be'/>
<id>urn:sha1:ae2fbe4ff3f3368325629d884fe0d53f23d8f8be</id>
<content type='text'>
commit 8b8b36834d0fff67fc8668093f4312dd04dcf21d upstream.

The per_cpu buffers are created one per possible CPU. But these do
not mean that those CPUs are online, nor do they even exist.

With the addition of the ring buffer polling, it assumes that the
caller polls on an existing buffer. But this is not the case if
the user reads trace_pipe from a CPU that does not exist, and this
causes the kernel to crash.

Simple fix is to check the cpu against buffer bitmask against to see
if the buffer was allocated or not and return -ENODEV if it is
not.

More updates were done to pass the -ENODEV back up to userspace.

Link: http://lkml.kernel.org/r/5393DB61.6060707@oracle.com

Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: provide interface for audio driver to query cdclk</title>
<updated>2014-07-09T18:21:26Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2014-07-04T02:00:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8143820319a5e7d617c122c70b58e1fdbd1b2c6e'/>
<id>urn:sha1:8143820319a5e7d617c122c70b58e1fdbd1b2c6e</id>
<content type='text'>
commit c149dcb5c60bfea8871f16dfcc0690255eeb825f upstream.

For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private interface for the
audio driver to query CDCLK.

This is a stopgap solution until a more generic interface between audio
and display drivers has been implemented.

Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Damien Lespiau &lt;damien.lespiau@intel.com&gt;
Signed-off-by: Mengdong Lin &lt;mengdong.lin@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915, HD-audio: Don't continue probing when nomodeset is given</title>
<updated>2014-07-09T18:21:26Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2014-06-13T13:14:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ab2a211c3d3d2f871f79f0a48c73b8df653219ea'/>
<id>urn:sha1:ab2a211c3d3d2f871f79f0a48c73b8df653219ea</id>
<content type='text'>
commit 74b0c2d75fb4cc89173944e6d8f9eb47aca0c343 upstream.

When a machine is booted with nomodeset option, i915 driver skips the
whole initialization.  Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_well() wrongly but still continues probing,
even though it doesn't work at all.

In this patch, both functions are changed to return an error in case
of uninitialized state instead of WARN_ON(), so that HD-audio driver
can give up HDMI controller initialization at the right time.

Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: gadget: f_fs: resurect usb_functionfs_descs_head structure</title>
<updated>2014-07-09T18:21:24Z</updated>
<author>
<name>Michal Nazarewicz</name>
<email>mina86@mina86.com</email>
</author>
<published>2014-06-13T13:38:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=40c409dcedd38eb34785ba0cfde6de0936c56a2e'/>
<id>urn:sha1:40c409dcedd38eb34785ba0cfde6de0936c56a2e</id>
<content type='text'>
commit 09122141785348bf9539762a5f5dbbae3761c783 upstream.

Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools.  Its removel in commit
[ac8dde1: “Add flags to descriptors block”] was an oversight
leading to build breakage for such tools.

Bring it back so that old user space tools can still be build
without problems on newer kernel versions.

Reported-by: Lad, Prabhakar &lt;prabhakar.csengg@gmail.com&gt;
Reported-by: Krzysztof Opasiak &lt;k.opasiak@samsung.com&gt;
Signed-off-by: Michal Nazarewicz &lt;mina86@mina86.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb-storage/SCSI: Add broken_fua blacklist flag</title>
<updated>2014-07-09T18:21:23Z</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2014-06-30T15:04:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b1154a920603b7bfc7c7d0d27b1abd67d0e56227'/>
<id>urn:sha1:b1154a920603b7bfc7c7d0d27b1abd67d0e56227</id>
<content type='text'>
commit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream.

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs.  This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Michael Büsch &lt;m@bues.ch&gt;
Tested-by: Michael Büsch &lt;m@bues.ch&gt;
Acked-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
CC: Matthew Dharm &lt;mdharm-usb@one-eyed-alien.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: use the scsi data buffer length to extract transfer size</title>
<updated>2014-07-09T18:21:23Z</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2014-06-24T14:59:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=65e98a83a95c5c3e5b6e686173054a557626909c'/>
<id>urn:sha1:65e98a83a95c5c3e5b6e686173054a557626909c</id>
<content type='text'>
commit 5616b0a46ed82eb9a093f752fc4d7bd3cc688583 upstream.

Commit 8846bab180fa introduced a helper that can be used to query the
wire transfer size for a SCSI command taking protection information into
account.

However, some commands do not have a 1:1 mapping between the block range
they work on and the payload size (discard, write same). After the
scatterlist has been set up these requests use __data_len to store the
number of bytes to report completion on. This means that callers of
scsi_transfer_length() would get the wrong byte count for these types of
requests.

To overcome this we make scsi_transfer_length() use the scatterlist
length in the scsi_data_buffer as basis for the wire transfer
calculation instead of __data_len.

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Debugged-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Fixes: d77e65350f2d82dfa0557707d505711f5a43c8fd
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tracing: Fix syscall_*regfunc() vs copy_process() race</title>
<updated>2014-07-07T01:59:12Z</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2014-04-13T18:58:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=22e7649524323c35d868c639f349164fb8ef8455'/>
<id>urn:sha1:22e7649524323c35d868c639f349164fb8ef8455</id>
<content type='text'>
commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.

syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.

Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.

Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com

Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ptrace,x86: force IRET path after a ptrace_stop()</title>
<updated>2014-07-07T01:59:12Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-07-03T19:43:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ac79fd540a0282460a22955753056c4a636b620b'/>
<id>urn:sha1:ac79fd540a0282460a22955753056c4a636b620b</id>
<content type='text'>
commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values.  That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'.  Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Andy Lutomirski &lt;luto@amacapital.net&gt;
Acked-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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