Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 7月, 2013 1 次提交
  3. 19 7月, 2013 1 次提交
  5. 16 7月, 2013 1 次提交
  7. 04 7月, 2013 1 次提交
    • K
      clean up scary strncpy(dst, src, strlen(src)) uses · 096a8aac
      由 Kees Cook 提交于 
      Fix various weird constructions of strncpy(dst, src, strlen(src)).

Length limits should be about the space available in the destination,
not repurposed as a method to either always include or always exclude a
trailing NULL byte.  Either the NULL should always be copied (using
strlcpy), or it should not be copied (using something like memcpy).
Readable code should not depend on the weird behavior of strncpy when it
hits the length limit.  Better to avoid the anti-pattern entirely.

[akpm@linux-foundation.org: revert getdelays.c part due to missing bsd/string.h]
Signed-off-by: NKees Cook <keescook@chromium.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	[staging]
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>	[acpi]
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ursula Braun <ursula.braun@de.ibm.com>
Cc: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      096a8aac
  9. 01 7月, 2013 8 次提交
  11. 28 6月, 2013 1 次提交
  13. 27 6月, 2013 17 次提交
  15. 26 6月, 2013 5 次提交
  17. 14 6月, 2013 1 次提交
  19. 01 6月, 2013 4 次提交
    • S
      [SCSI] zfcp: status read buffers on first adapter open with link down · 9edf7d75
      由 Steffen Maier 提交于 
      Commit 64deb6ef
"[SCSI] zfcp: Use status_read_buf_num provided by FCP channel"
started using a value returned by the channel but only evaluated the value
if the fabric link is up.
Commit 8d88cf3f
"[SCSI] zfcp: Update status read mempool"
introduced mempool resizings based on the above value.
On setting an FCP device online for the very first time since boot, a new
zeroed adapter object is allocated. If the link is down, the number of
status read requests remains zero. Since just the config data exchange is
incomplete, we proceed with adapter open recovery. However, we
unconditionally call mempool_resize with adapter->stat_read_buf_num == 0 in
this case.

This causes a kernel message "kernel BUG at mm/mempool.c:131!" in process
"zfcperp<FCP-device-bus-ID>" with last function mempool_resize in Krnl PSW
and zfcp_erp_thread in the Call Trace.

Don't evaluate channel values which are invalid on link down. The number of
status read requests is always valid, evaluated, and set to a positive
minimum greater than zero. The adapter open recovery can proceed and the
channel has status read buffers to inform us on a future link up event.
While we are not aware of any other code path that could result in mempool
resize attempts of size zero, we still also initialize the number of status
read buffers to be posted to a static minimum number on adapter object
allocation.
Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #2.6.35+
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      9edf7d75
    • M
      [SCSI] zfcp: remove access control tables interface · 663e0890
      由 Martin Peschke 提交于 
      This patch removes an interface that was used to manage access control
tables within the HBA. The patch consequently removes the handling
for conditions related to those access control tables, too.

That initiator-based access control feature was only needed until the
introduction of NPIV and was withdrawn with z10 years ago.
It's time to cleanup the corresponding device driver code.
Signed-off-by: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      663e0890
    • S
      [SCSI] zfcp: module parameter dbflevel for early debugging · bf3ea3ae
      由 Steffen Maier 提交于 
      So far, we could only increase the s390dbf log level after an FCP
device has been initially set online for it to create the dbf entries
required to adjust the level.

Introduce zfcp.dbflevel as counterpart to the already existing
zfcp.dbfsize to enable debugging of e.g. setting an FCP device online.
Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      bf3ea3ae
    • S
      [SCSI] zfcp: block queue limits with data router · 5fea4291
      由 Steffen Maier 提交于 
      Commit 86a9668a
"[SCSI] zfcp: support for hardware data router"
reduced the initial block queue limits in the scsi_host_template to the
absolute minimum and adjusted them later on. However, the adjustment was
too late for the BSG devices of Scsi_Host and fc_host.

Therefore, ioctl(..., SG_IO, ...) with request or response size > 4kB to a
BSG device of an fc_host or a Scsi_Host fails with EINVAL. As a result,
users of such ioctl such as HBA_SendCTPassThru() in libzfcphbaapi return
with error HBA_STATUS_ERROR.

Initialize the block queue limits in zfcp_scsi_host_template to the
greatest common denominator (GCD).

While we cannot exploit the slightly enlarged maximum request size with
data router, this should be neglectible. Doing so also avoids running into
trouble after live guest relocation (LGR) / migration from a data router
FCP device to an FCP device that does not support data router. In that
case, zfcp would figure out the new limits on adapter recovery, but the
fc_host and Scsi_Host (plus in fact all sdevs) still exist with the old and
now too large queue limits.

It should also OK, not to use half the size as in the DIX case, because
fc_host and Scsi_Host do not transport FCP requests including SCSI commands
using protection data.
Signed-off-by: NSteffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: NMartin Peschke <mpeschke@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> #3.2+
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      5fea4291