Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 10月, 2017 5 次提交
  3. 19 10月, 2017 5 次提交
  5. 18 10月, 2017 9 次提交
    • L
      Merge tag 'enforcement-4.14-rc6' of... · 3e0cc09a
      由 Linus Torvalds 提交于 
      Merge tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull enforcement policy update from Greg KH:
 "Documentation: Add a file explaining the requested Linux kernel
  license enforcement policy

  Here's a new file to the kernel's Documentation directory. It adds a
  short document describing the views of how the Linux kernel community
  feels about enforcing the license of the kernel.

  The patch has been reviewed by a large number of kernel developers
  already, as seen by their acks on the patch, and their agreement of
  the statement with their names on it. The location of the file was
  also agreed upon by the Documentation maintainer, so all should be
  good there.

  For some background information about this statement, see this article
  written by some of the kernel developers involved in drafting it:

	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/

  and this article that answers a number of questions that came up in
  the discussion of this statement with the kernel developer community:

	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/

  If anyone has any further questions about it, please let me, and the
  TAB members, know and we will be glad to help answer them"

* tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  Documentation: Add a file explaining the Linux kernel license enforcement policy
      3e0cc09a
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 96b0e525
      由 Linus Torvalds 提交于 
      Pull s390 fixes from Martin Schwidefsky:
 "Two bug fixes:

   - A fix for cputime accounting vs CPU hotplug

   - Add two options to zfcpdump_defconfig to make SCSI dump work again"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390: fix zfcpdump-config
  s390/cputime: fix guest/irq/softirq times after CPU hotplug
      96b0e525
    • L
      Merge tag 'trace-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 503f7e29
      由 Linus Torvalds 提交于 
      Pull tracing fix from Steven Rostedt:
 "Testing a new trace event format, I triggered a bug by doing:

    # modprobe trace-events-sample
    # echo 1 > /sys/kernel/debug/tracing/events/sample-trace/enable
    # rmmod trace-events-sample

  This would cause an oops. The issue is that I added another trace
  event sample that reused a reg function of another trace event to
  create a thread to call the tracepoints. The problem was that the reg
  function couldn't handle nested calls (reg; reg; unreg; unreg;) and
  created two threads (instead of one) and only removed one on exit.

  This isn't a critical bug as the bug is only in sample code. But
  sample code should be free of known bugs to prevent others from
  copying it. This is why this is also marked for stable"

* tag 'trace-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing/samples: Fix creation and deletion of simple_thread_fn creation
      503f7e29
    • T
      ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal · a91d6612
      由 Takashi Iwai 提交于 
      The commit 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
converted the get_kctl_0dB_offset() call for killing set_fs() usage in
HD-audio codec code.  The conversion assumed that the TLV callback
used in HD-audio code is only snd_hda_mixer_amp() and applies the TLV
calculation locally.

Although this assumption is correct, and all slave kctls are actually
with that callback, the current code is still utterly buggy; it
doesn't hit this condition and falls back to the next check.  It's
because the function gets called after adding slave kctls to vmaster.
By assigning a slave kctl, the slave kctl object is faked inside
vmaster code, and the whole kctl ops are overridden.  Thus the
callback op points to a different value from what we've assumed.

More badly, as reported by the KERNEXEC and UDEREF features of PaX,
the code flow turns into the unexpected pitfall.  The next fallback
check is SNDRV_CTL_ELEM_ACCESS_TLV_READ access bit, and this always
hits for each kctl with TLV.  Then it evaluates the callback function
pointer wrongly as if it were a TLV array.  Although currently its
side-effect is fairly limited, this incorrect reference may lead to an
unpleasant result.

For addressing the regression, this patch introduces a new helper to
vmaster code, snd_ctl_apply_vmaster_slaves().  This works similarly
like the existing map_slaves() in hda_codec.c: it loops over the slave
list of the given master, and applies the given function to each
slave.  Then the initializer function receives the right kctl object
and we can compare the correct pointer instead of the faked one.

Also, for catching the similar breakage in future, give an error
message when the unexpected TLV callback is found and bail out
immediately.

Fixes: 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
Reported-by: NPaX Team <pageexec@freemail.hu>
Cc: <stable@vger.kernel.org> # v4.13
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a91d6612
    • T
      ALSA: hda: Remove superfluous '-' added by printk conversion · 6bf88a34
      由 Takashi Iwai 提交于 
      While converting the error messages to the standard macros in the
commit 4e76a883 ("ALSA: hda - Replace with standard printk"), a
superfluous '-' slipped in the code mistakenly.  Its influence is
almost negligible, merely shows a dB value as negative integer instead
of positive integer (or vice versa) in the rare error message.
So let's kill this embarrassing byte to show more correct value.

Fixes: 4e76a883 ("ALSA: hda - Replace with standard printk")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6bf88a34
    • T
      ALSA: hda: Abort capability probe at invalid register read · 098a0a62
      由 Takashi Iwai 提交于 
      The loop in snd_hdac_bus_parse_capabilities() may go to nirvana when
it hits an invalid register value read:

 BUG: unable to handle kernel paging request at ffffad5dc41f3fff
 IP: pci_azx_readl+0x5/0x10 [snd_hda_intel]
 Call Trace:
  snd_hdac_bus_parse_capabilities+0x3c/0x1f0 [snd_hda_core]
  azx_probe_continue+0x7d5/0x940 [snd_hda_intel]
  .....

This happened on a new Intel machine, and we need to check the value
and abort the loop accordingly.

[Note: the fixes tag below indicates only the commit where this patch
 can be applied; the original problem was introduced even before that
 commit]

Fixes: 6720b384 ("ALSA: hda - move bus_parse_capabilities to core")
Cc: <stable@vger.kernel.org>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      098a0a62
    • B
      ALSA: seq: Enable 'use' locking in all configurations · 8009d506
      由 Ben Hutchings 提交于 
      The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
enabled.  This might once have been OK in non-preemptible
configurations, but even in that case snd_seq_read() may sleep while
relying on a 'use' lock.  So always use the proper implementations.

Cc: stable@vger.kernel.org
Signed-off-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      8009d506
    • L
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · ebe6e90c
      由 Linus Torvalds 提交于 
      Pull SCSI fixes from James Bottomley:
 "Four mostly error leg fixes and one more important regression in a
  prior commit (the qla2xxx one)"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: fc: check for rport presence in fc_block_scsi_eh
  scsi: qla2xxx: Fix uninitialized work element
  scsi: libiscsi: fix shifting of DID_REQUEUE host byte
  scsi: libfc: fix a deadlock in fc_rport_work
  scsi: fixup kernel warning during rmmod()
      ebe6e90c
    • S
      tracing/samples: Fix creation and deletion of simple_thread_fn creation · 6575257c
      由 Steven Rostedt (VMware) 提交于 
      Commit 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and
DEFINE_EVENT()") added template examples for all the events. It created a
DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg
functions.

Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace
events caused the foo_bar_reg to be called twice, creating the test thread
twice. The foo_bar_unreg would remove it only once, even if it was called
multiple times, leaving a thread existing when the module is unloaded,
causing an oops.

Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by
multiple trace events.

Cc: stable@vger.kernel.org
Fixes: 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()")
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      6575257c
  7. 17 10月, 2017 6 次提交
    • L
      fs: Avoid invalidation in interrupt context in dio_complete() · ffe51f01
      由 Lukas Czerner 提交于 
      Currently we try to defer completion of async DIO to the process context
in case there are any mapped pages associated with the inode so that we
can invalidate the pages when the IO completes. However the check is racy
and the pages can be mapped afterwards. If this happens we might end up
calling invalidate_inode_pages2_range() in dio_complete() in interrupt
context which could sleep. This can be reproduced by generic/451.

Fix this by passing the information whether we can or can't invalidate
to the dio_complete(). Thanks Eryu Guan for reporting this and Jan Kara
for suggesting a fix.

Fixes: 332391a9 ("fs: Fix page cache inconsistency when mixing buffered and AIO DIO")
Reported-by: NEryu Guan <eguan@redhat.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Tested-by: NEryu Guan <eguan@redhat.com>
Signed-off-by: NLukas Czerner <lczerner@redhat.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
      ffe51f01
    • L
      Merge tag 'media/v4.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 3728e6a2
      由 Linus Torvalds 提交于 
      Pull media fixes from Mauro Carvalho Chehab:
 "Core fixes:
   - cec: Respond to unregistered initiators, when applicable
   - dvb_frontend: only use kref after initialized

  Driver-specific fixes:
   - qcom, camss: Make function vfe_set_selection static
   - qcom: VIDEO_QCOM_CAMSS should depend on HAS_DMA
   - s5p-cec: add NACK detection support
   - media: staging/imx: Fix uninitialized variable warning
   - dib3000mc: i2c transfers over usb cannot be done from stack
   - venus: init registered list on streamoff"

* tag 'media/v4.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  media: dvb_frontend: only use kref after initialized
  media: platform: VIDEO_QCOM_CAMSS should depend on HAS_DMA
  media: cec: Respond to unregistered initiators, when applicable
  media: s5p-cec: add NACK detection support
  media: staging/imx: Fix uninitialized variable warning
  media: qcom: camss: Make function vfe_set_selection static
  media: venus: init registered list on streamoff
  media: dvb: i2c transfers over usb cannot be done from stack
      3728e6a2
    • A
      xfs: move two more RT specific functions into CONFIG_XFS_RT · 785545c8
      由 Arnd Bergmann 提交于 
      The last cleanup introduced two harmless warnings:

fs/xfs/xfs_fsmap.c:480:1: warning: '__xfs_getfsmap_rtdev' defined but not used
fs/xfs/xfs_fsmap.c:372:1: warning: 'xfs_getfsmap_rtdev_rtbitmap_helper' defined but not used

This moves those two functions as well.

Fixes: bb9c2e54 ("xfs: move more RT specific code under CONFIG_XFS_RT")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NBrian Foster <bfoster@redhat.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      785545c8
    • B
      xfs: trim writepage mapping to within eof · 40214d12
      由 Brian Foster 提交于 
      The writeback rework in commit fbcc0256 ("xfs: Introduce
writeback context for writepages") introduced a subtle change in
behavior with regard to the block mapping used across the
->writepages() sequence. The previous xfs_cluster_write() code would
only flush pages up to EOF at the time of the writepage, thus
ensuring that any pages due to file-extending writes would be
handled on a separate cycle and with a new, updated block mapping.

The updated code establishes a block mapping in xfs_writepage_map()
that could extend beyond EOF if the file has post-eof preallocation.
Because we now use the generic writeback infrastructure and pass the
cached mapping to each writepage call, there is no implicit EOF
limit in place. If eofblocks trimming occurs during ->writepages(),
any post-eof portion of the cached mapping becomes invalid. The
eofblocks code has no means to serialize against writeback because
there are no pages associated with post-eof blocks. Therefore if an
eofblocks trim occurs and is followed by a file-extending buffered
write, not only has the mapping become invalid, but we could end up
writing a page to disk based on the invalid mapping.

Consider the following sequence of events:

- A buffered write creates a delalloc extent and post-eof
  speculative preallocation.
- Writeback starts and on the first writepage cycle, the delalloc
  extent is converted to real blocks (including the post-eof blocks)
  and the mapping is cached.
- The file is closed and xfs_release() trims post-eof blocks. The
  cached writeback mapping is now invalid.
- Another buffered write appends the file with a delalloc extent.
- The concurrent writeback cycle picks up the just written page
  because the writeback range end is LLONG_MAX. xfs_writepage_map()
  attributes it to the (now invalid) cached mapping and writes the
  data to an incorrect location on disk (and where the file offset is
  still backed by a delalloc extent).

This problem is reproduced by xfstests test generic/464, which
triggers racing writes, appends, open/closes and writeback requests.

To address this problem, trim the mapping used during writeback to
within EOF when the mapping is validated. This ensures the mapping
is revalidated for any pages encountered beyond EOF as of the time
the current mapping was cached or last validated.
Reported-by: NEryu Guan <eguan@redhat.com>
Diagnosed-by: NEryu Guan <eguan@redhat.com>
Signed-off-by: NBrian Foster <bfoster@redhat.com>
Reviewed-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      40214d12
    • E
      fs: invalidate page cache after end_io() in dio completion · 5e25c269
      由 Eryu Guan 提交于 
      Commit 332391a9 ("fs: Fix page cache inconsistency when mixing
buffered and AIO DIO") moved page cache invalidation from
iomap_dio_rw() to iomap_dio_complete() for iomap based direct write
path, but before the dio->end_io() call, and it re-introdued the bug
fixed by commit c771c14b ("iomap: invalidate page caches should
be after iomap_dio_complete() in direct write").

I found this because fstests generic/418 started failing on XFS with
v4.14-rc3 kernel, which is the regression test for this specific
bug.

So similarly, fix it by moving dio->end_io() (which does the
unwritten extent conversion) before page cache invalidation, to make
sure next buffer read reads the final real allocations not unwritten
extents. I also add some comments about why should end_io() go first
in case we get it wrong again in the future.

Note that, there's no such problem in the non-iomap based direct
write path, because we didn't remove the page cache invalidation
after the ->direct_IO() in generic_file_direct_write() call, but I
decided to fix dio_complete() too so we don't leave a landmine
there, also be consistent with iomap_dio_complete().

Fixes: 332391a9 ("fs: Fix page cache inconsistency when mixing buffered and AIO DIO")
Signed-off-by: NEryu Guan <eguan@redhat.com>
Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Reviewed-by: NLukas Czerner <lczerner@redhat.com>
      5e25c269
    • D
      xfs: cancel dirty pages on invalidation · 793d7dbe
      由 Dave Chinner 提交于 
      Recently we've had warnings arise from the vm handing us pages
without bufferheads attached to them. This should not ever occur
in XFS, but we don't defend against it properly if it does. The only
place where we remove bufferheads from a page is in
xfs_vm_releasepage(), but we can't tell the difference here between
"page is dirty so don't release" and "page is dirty but is being
invalidated so release it".

In some places that are invalidating pages ask for pages to be
released and follow up afterward calling ->releasepage by checking
whether the page was dirty and then aborting the invalidation. This
is a possible vector for releasing buffers from a page but then
leaving it in the mapping, so we really do need to avoid dirty pages
in xfs_vm_releasepage().

To differentiate between invalidated pages and normal pages, we need
to clear the page dirty flag when invalidating the pages. This can
be done through xfs_vm_invalidatepage(), and will result
xfs_vm_releasepage() seeing the page as clean which matches the
bufferhead state on the page after calling block_invalidatepage().

Hence we can re-add the page dirty check in xfs_vm_releasepage to
catch the case where we might be releasing a page that is actually
dirty and so should not have the bufferheads on it removed. This
will remove one possible vector of "dirty page with no bufferheads"
and so help narrow down the search for the root cause of that
problem.
Signed-Off-By: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      793d7dbe
  9. 16 10月, 2017 5 次提交
  11. 15 10月, 2017 10 次提交