1. 18 12月, 2013 9 次提交
  2. 13 12月, 2013 6 次提交
  3. 12 12月, 2013 1 次提交
  4. 11 12月, 2013 3 次提交
  5. 10 12月, 2013 3 次提交
    • T
      ALSA: compress: Fix 64bit ABI incompatibility · 6733cf57
      Takashi Iwai 提交于
      snd_pcm_uframes_t is defined as unsigned long so it would take
      different sizes depending on 32 or 64bit architectures.  As we don't
      want this ABI incompatibility, and there is no real 64bit user yet,
      let's make it the fixed size with __u32.
      
      Also bump the protocol version number to 0.1.2.
      Acked-by: NVinod Koul <vinod.koul@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6733cf57
    • S
      ALSA: memalloc.h - fix wrong truncation of dma_addr_t · 932e9dec
      Stefano Panella 提交于
      When running a 32bit kernel the hda_intel driver is still reporting
      a 64bit dma_mask if the HW supports it.
      
      From sound/pci/hda/hda_intel.c:
      
              /* allow 64bit DMA address if supported by H/W */
              if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
                      pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
              else {
                      pci_set_dma_mask(pci, DMA_BIT_MASK(32));
                      pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
              }
      
      which means when there is a call to dma_alloc_coherent from
      snd_malloc_dev_pages a machine address bigger than 32bit can be returned.
      This can be true in particular if running  the 32bit kernel as a pv dom0
      under the Xen Hypervisor or PAE on bare metal.
      
      The problem is that when calling setup_bdle to program the BLE the
      dma_addr_t returned from the dma_alloc_coherent is wrongly truncated
      from snd_sgbuf_get_addr if running a 32bit kernel:
      
      static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab,
                                                 size_t offset)
      {
              struct snd_sg_buf *sgbuf = dmab->private_data;
              dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
              addr &= PAGE_MASK;
              return addr + offset % PAGE_SIZE;
      }
      
      where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr.
      
      Without this patch the HW will fetch the 32bit truncated address,
      which is not the one obtained from dma_alloc_coherent and will result
      to a non working audio but can corrupt host memory at a random location.
      
      The current patch apply to v3.13-rc3-74-g6c843f5
      Signed-off-by: NStefano Panella <stefano.panella@citrix.com>
      Reviewed-by: NFrediano Ziglio <frediano.ziglio@citrix.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      932e9dec
    • P
      [media] videobuf2: Add support for file access mode flags for DMABUF exporting · c1b96a23
      Philipp Zabel 提交于
      Currently it is not possible for userspace to map a DMABUF exported buffer
      with write permissions. This patch allows to also pass O_RDONLY/O_RDWR when
      exporting the buffer, so that userspace may map it with write permissions.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      c1b96a23
  6. 09 12月, 2013 1 次提交
  7. 08 12月, 2013 2 次提交
  8. 06 12月, 2013 3 次提交
  9. 03 12月, 2013 8 次提交
  10. 02 12月, 2013 2 次提交
    • E
      security: shmem: implement kernel private shmem inodes · c7277090
      Eric Paris 提交于
      We have a problem where the big_key key storage implementation uses a
      shmem backed inode to hold the key contents.  Because of this detail of
      implementation LSM checks are being done between processes trying to
      read the keys and the tmpfs backed inode.  The LSM checks are already
      being handled on the key interface level and should not be enforced at
      the inode level (since the inode is an implementation detail, not a
      part of the security model)
      
      This patch implements a new function shmem_kernel_file_setup() which
      returns the equivalent to shmem_file_setup() only the underlying inode
      has S_PRIVATE set.  This means that all LSM checks for the inode in
      question are skipped.  It should only be used for kernel internal
      operations where the inode is not exposed to userspace without proper
      LSM checking.  It is possible that some other users of
      shmem_file_setup() should use the new interface, but this has not been
      explored.
      
      Reproducing this bug is a little bit difficult.  The steps I used on
      Fedora are:
      
       (1) Turn off selinux enforcing:
      
      	setenforce 0
      
       (2) Create a huge key
      
      	k=`dd if=/dev/zero bs=8192 count=1 | keyctl padd big_key test-key @s`
      
       (3) Access the key in another context:
      
      	runcon system_u:system_r:httpd_t:s0-s0:c0.c1023 keyctl print $k >/dev/null
      
       (4) Examine the audit logs:
      
      	ausearch -m AVC -i --subject httpd_t | audit2allow
      
      If the last command's output includes a line that looks like:
      
      	allow httpd_t user_tmpfs_t:file { open read };
      
      There was an inode check between httpd and the tmpfs filesystem.  With
      this patch no such denial will be seen.  (NOTE! you should clear your
      audit log if you have tested for this previously)
      
      (Please return you box to enforcing)
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Hugh Dickins <hughd@google.com>
      cc: linux-mm@kvack.org
      c7277090
    • D
      KEYS: Fix multiple key add into associative array · 23fd78d7
      David Howells 提交于
      If sufficient keys (or keyrings) are added into a keyring such that a node in
      the associative array's tree overflows (each node has a capacity N, currently
      16) and such that all N+1 keys have the same index key segment for that level
      of the tree (the level'th nibble of the index key), then assoc_array_insert()
      calls ops->diff_objects() to indicate at which bit position the two index keys
      vary.
      
      However, __key_link_begin() passes a NULL object to assoc_array_insert() with
      the intention of supplying the correct pointer later before we commit the
      change.  This means that keyring_diff_objects() is given a NULL pointer as one
      of its arguments which it does not expect.  This results in an oops like the
      attached.
      
      With the previous patch to fix the keyring hash function, this can be forced
      much more easily by creating a keyring and only adding keyrings to it.  Add any
      other sort of key and a different insertion path is taken - all 16+1 objects
      must want to cluster in the same node slot.
      
      This can be tested by:
      
      	r=`keyctl newring sandbox @s`
      	for ((i=0; i<=16; i++)); do keyctl newring ring$i $r; done
      
      This should work fine, but oopses when the 17th keyring is added.
      
      Since ops->diff_objects() is always called with the first pointer pointing to
      the object to be inserted (ie. the NULL pointer), we can fix the problem by
      changing the to-be-inserted object pointer to point to the index key passed
      into assoc_array_insert() instead.
      
      Whilst we're at it, we also switch the arguments so that they are the same as
      for ->compare_object().
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
      IP: [<ffffffff81191ee4>] hash_key_type_and_desc+0x18/0xb0
      ...
      RIP: 0010:[<ffffffff81191ee4>] hash_key_type_and_desc+0x18/0xb0
      ...
      Call Trace:
       [<ffffffff81191f9d>] keyring_diff_objects+0x21/0xd2
       [<ffffffff811f09ef>] assoc_array_insert+0x3b6/0x908
       [<ffffffff811929a7>] __key_link_begin+0x78/0xe5
       [<ffffffff81191a2e>] key_create_or_update+0x17d/0x36a
       [<ffffffff81192e0a>] SyS_add_key+0x123/0x183
       [<ffffffff81400ddb>] tracesys+0xdd/0xe2
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NStephen Gallagher <sgallagh@redhat.com>
      23fd78d7
  11. 01 12月, 2013 1 次提交
  12. 29 11月, 2013 1 次提交
    • M
      [SCSI] Disable WRITE SAME for RAID and virtual host adapter drivers · 54b2b50c
      Martin K. Petersen 提交于
      Some host adapters do not pass commands through to the target disk
      directly. Instead they provide an emulated target which may or may not
      accurately report its capabilities. In some cases the physical device
      characteristics are reported even when the host adapter is processing
      commands on the device's behalf. This can lead to adapter firmware hangs
      or excessive I/O errors.
      
      This patch disables WRITE SAME for devices connected to host adapters
      that provide an emulated target. Driver writers can disable WRITE SAME
      by setting the no_write_same flag in the host adapter template.
      
      [jejb: fix up rejections due to eh_deadline patch]
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      54b2b50c