{"push_id":2169147503,"size":62,"distinct_size":0,"ref":"refs/heads/caf/3.10/caf/korg/linux-3.2.y","head":"07a40fa22291c6d10583ab00fc8589e3c2088372","before":"8518814021e098a07b305a3c98620fc414ac0f20","commits":[{"sha":"a7f3619d51e620c157dad6361ce74143adb1903f","author":{"name":"Noa Osherovich","email":"5ecb6bfdb1cd2131d0645621186ccff52c180a8b@mellanox.com"},"message":"IB/core: Fix the validations of a multicast LID in attach or detach operations\n\ncommit 5236333592244557a19694a51337df6ac018f0a7 upstream.\n\nRoCE Annex (A16.9.10/11) declares that during attach (detach) QP to a\nmulticast group, if the QP is associated with a RoCE port, the\nmulticast group MLID is unused and is ignored.\n\nDuring attach or detach multicast, when the QP is associated with a\nport, it is enough to check the port's link layer and validate the\nLID only if it is Infiniband. Otherwise, avoid validating the\nmulticast LID.\n\nFixes: 8561eae60ff9 (\"IB/core: For multicast functions, verify that LIDs are multicast LIDs\")\nSigned-off-by: Noa Osherovich <noaos@mellanox.com>\nReviewed-by: Moni Shoua <monis@mellanox.com>\nSigned-off-by: Leon Romanovsky <leon@kernel.org>\nSigned-off-by: Doug Ledford <dledford@redhat.com>\n[bwh: Backported to 3.2: use literal number instead of IB_MULTICAST_LID_BASE]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/a7f3619d51e620c157dad6361ce74143adb1903f"},{"sha":"b88cd8f4f1dd0b64e12eb0a944270380f88a4755","author":{"name":"Oleg Nesterov","email":"66df68a59e3b21ba65b9e7f3fee04bb7abd7ddc2@redhat.com"},"message":"signal: move the \"sig < SIGRTMIN\" check into siginmask(sig)\n\ncommit 5c8ccefdf46c5f87d87b694c7fbc04941c2c99a5 upstream.\n\nAll the users of siginmask() must ensure that sig < SIGRTMIN.  sig_fatal()\ndoesn't and this is wrong:\n\n\tUBSAN: Undefined behaviour in kernel/signal.c:911:6\n\tshift exponent 32 is too large for 32-bit type 'long unsigned int'\n\nthe patch doesn't add the neccesary check to sig_fatal(), it moves the\ncheck into siginmask() and updates other callers.\n\nLink: http://lkml.kernel.org/r/20160517195052.GA15187@redhat.com\nReported-by: Meelis Roos <mroos@linux.ee>\nSigned-off-by: Oleg Nesterov <oleg@redhat.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/b88cd8f4f1dd0b64e12eb0a944270380f88a4755"},{"sha":"00e1fb59eddc1de07358dde20ae3aa50e49f043d","author":{"name":"Eric W. Biederman","email":"e4ccc9f9b54eebd6cb8fc7643b8083f628b68ff2@xmission.com"},"message":"fcntl: Don't use ambiguous SIG_POLL si_codes\n\ncommit d08477aa975e97f1dc64c0ae59cebf98520456ce upstream.\n\nWe have a weird and problematic intersection of features that when\nthey all come together result in ambiguous siginfo values, that\nwe can not support properly.\n\n- Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.\n\n- Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc\n  that imply they are signal specific si_codes and using the\n  aforementioned arbitrary signal to deliver them.\n\n- Supporting injection of arbitrary siginfo values for debugging and\n  checkpoint/restore.\n\nThe result is that just looking at siginfo si_codes of 1 to 6 are\nambigious.  It could either be a signal specific si_code or it could\nbe a generic si_code.\n\nFor most of the kernel this is a non-issue but for sending signals\nwith siginfo it is impossible to play back the kernel signals and\nget the same result.\n\nStrictly speaking when the si_code was changed from SI_SIGIO to\nPOLL_IN and friends between 2.2 and 2.4 this functionality was not\nambiguous, as only real time signals were supported.  Before 2.4 was\nreleased the kernel began supporting siginfo with non realtime signals\nso they could give details of why the signal was sent.\n\nThe result is that if F_SETSIG is set to one of the signals with signal\nspecific si_codes then user space can not know why the signal was sent.\n\nI grepped through a bunch of userspace programs using debian code\nsearch to get a feel for how often people choose a signal that results\nin an ambiguous si_code.  I only found one program doing so and it was\nusing SIGCHLD to test the F_SETSIG functionality, and did not appear\nto be a real world usage.\n\nTherefore the ambiguity does not appears to be a real world problem in\npractice.  Remove the ambiguity while introducing the smallest chance\nof breakage by changing the si_code to SI_SIGIO when signals with\nsignal specific si_codes are targeted.\n\nFixes: v2.3.40 -- Added support for queueing non-rt signals\nFixes: v2.3.21 -- Changed the si_code from SI_SIGIO\nSigned-off-by: \"Eric W. Biederman\" <ebiederm@xmission.com>\n[bwh: Backported to 3.2: adjust filename]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/00e1fb59eddc1de07358dde20ae3aa50e49f043d"},{"sha":"d89a5d32aa10c6d3ef5cbfd389de549841787613","author":{"name":"Rui Teng","email":"53d453d1ae353493f193be1cd6567e37c281e8ff@linux.vnet.ibm.com"},"message":"powerpc/mm: Fix check of multiple 16G pages from device tree\n\ncommit 23493c121912a39f0262e0dbeb236e1d39efa4d5 upstream.\n\nThe offset of hugepage block will not be 16G, if the expected\npage is more than one. Calculate the totol size instead of the\nhardcode value.\n\nFixes: 4792adbac9eb (\"powerpc: Don't use a 16G page if beyond mem= limits\")\nSigned-off-by: Rui Teng <rui.teng@linux.vnet.ibm.com>\nTested-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/d89a5d32aa10c6d3ef5cbfd389de549841787613"},{"sha":"f06f9d10d1be9028cc8eab6684904a99dfdc1120","author":{"name":"Aleksandr Bezzubikov","email":"8f29ef7ecb52bad38cd5a8c5ead25dc8325fceb8@gmail.com"},"message":"PCI: shpchp: Enable bridge bus mastering if MSI is enabled\n\ncommit 48b79a14505349a29b3e20f03619ada9b33c4b17 upstream.\n\nAn SHPC may generate MSIs to notify software about slot or controller\nevents (SHPC spec r1.0, sec 4.7).  A PCI device can only generate an MSI if\nit has bus mastering enabled.\n\nEnable bus mastering if the bridge contains an SHPC that uses MSI for event\nnotifications.\n\nSigned-off-by: Aleksandr Bezzubikov <zuban32s@gmail.com>\n[bhelgaas: changelog]\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nReviewed-by: Marcel Apfelbaum <marcel@redhat.com>\nAcked-by: Michael S. Tsirkin <mst@redhat.com>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/f06f9d10d1be9028cc8eab6684904a99dfdc1120"},{"sha":"d06189473cae286a6588e28f8baa101ebe799b37","author":{"name":"Edwin Török","email":"c2702b6ff978f57170a578ba0381f0b311a662e8@citrix.com"},"message":"dlm: avoid double-free on error path in dlm_device_{register,unregister}\n\ncommit 55acdd926f6b21a5cdba23da98a48aedf19ac9c3 upstream.\n\nCan be reproduced when running dlm_controld (tested on 4.4.x, 4.12.4):\n # seq 1 100 | xargs -P0 -n1 dlm_tool join\n # seq 1 100 | xargs -P0 -n1 dlm_tool leave\n\nmisc_register fails due to duplicate sysfs entry, which causes\ndlm_device_register to free ls->ls_device.name.\nIn dlm_device_deregister the name was freed again, causing memory\ncorruption.\n\nAccording to the comment in dlm_device_deregister the name should've been\nset to NULL when registration fails,\nso this patch does that.\n\nsysfs: cannot create duplicate filename '/dev/char/10:1'\n------------[ cut here ]------------\nwarning: cpu: 1 pid: 4450 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x56/0x70\nmodules linked in: msr rfcomm dlm ccm bnep dm_crypt uvcvideo\nvideobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev\nbtusb media btrtl btbcm btintel bluetooth ecdh_generic intel_rapl\nx86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm\nsnd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul\nghash_clmulni_intel thinkpad_acpi pcbc nvram snd_seq_midi\nsnd_seq_midi_event aesni_intel snd_hda_codec_realtek snd_hda_codec_generic\nsnd_rawmidi aes_x86_64 crypto_simd glue_helper snd_hda_intel snd_hda_codec\ncryptd intel_cstate arc4 snd_hda_core snd_seq snd_seq_device snd_hwdep\niwldvm intel_rapl_perf mac80211 joydev input_leds iwlwifi serio_raw\ncfg80211 snd_pcm shpchp snd_timer snd mac_hid mei_me lpc_ich mei soundcore\nsunrpc parport_pc ppdev lp parport autofs4 i915 psmouse\n e1000e ahci libahci i2c_algo_bit sdhci_pci ptp drm_kms_helper sdhci\npps_core syscopyarea sysfillrect sysimgblt fb_sys_fops drm wmi video\ncpu: 1 pid: 4450 comm: dlm_test.exe not tainted 4.12.4-041204-generic\nhardware name: lenovo 232425u/232425u, bios g2et82ww (2.02 ) 09/11/2012\ntask: ffff96b0cbabe140 task.stack: ffffb199027d0000\nrip: 0010:sysfs_warn_dup+0x56/0x70\nrsp: 0018:ffffb199027d3c58 eflags: 00010282\nrax: 0000000000000038 rbx: ffff96b0e2c49158 rcx: 0000000000000006\nrdx: 0000000000000000 rsi: 0000000000000086 rdi: ffff96b15e24dcc0\nrbp: ffffb199027d3c70 r08: 0000000000000001 r09: 0000000000000721\nr10: ffffb199027d3c00 r11: 0000000000000721 r12: ffffb199027d3cd1\nr13: ffff96b1592088f0 r14: 0000000000000001 r15: ffffffffffffffef\nfs:  00007f78069c0700(0000) gs:ffff96b15e240000(0000)\nknlgs:0000000000000000\ncs:  0010 ds: 0000 es: 0000 cr0: 0000000080050033\ncr2: 000000178625ed28 cr3: 0000000091d3e000 cr4: 00000000001406e0\ncall trace:\n sysfs_do_create_link_sd.isra.2+0x9e/0xb0\n sysfs_create_link+0x25/0x40\n device_add+0x5a9/0x640\n device_create_groups_vargs+0xe0/0xf0\n device_create_with_groups+0x3f/0x60\n ? snprintf+0x45/0x70\n misc_register+0x140/0x180\n device_write+0x6a8/0x790 [dlm]\n __vfs_write+0x37/0x160\n ? apparmor_file_permission+0x1a/0x20\n ? security_file_permission+0x3b/0xc0\n vfs_write+0xb5/0x1a0\n sys_write+0x55/0xc0\n ? sys_fcntl+0x5d/0xb0\n entry_syscall_64_fastpath+0x1e/0xa9\nrip: 0033:0x7f78083454bd\nrsp: 002b:00007f78069bbd30 eflags: 00000293 orig_rax: 0000000000000001\nrax: ffffffffffffffda rbx: 0000000000000006 rcx: 00007f78083454bd\nrdx: 000000000000009c rsi: 00007f78069bee00 rdi: 0000000000000005\nrbp: 00007f77f8000a20 r08: 000000000000fcf0 r09: 0000000000000032\nr10: 0000000000000024 r11: 0000000000000293 r12: 00007f78069bde00\nr13: 00007f78069bee00 r14: 000000000000000a r15: 00007f78069bbd70\ncode: 85 c0 48 89 c3 74 12 b9 00 10 00 00 48 89 c2 31 f6 4c 89 ef e8 2c c8\nff ff 4c 89 e2 48 89 de 48 c7 c7 b0 8e 0c a8 e8 41 e8 ed ff <0f> ff 48 89\ndf e8 00 d5 f4 ff 5b 41 5c 41 5d 5d c3 66 0f 1f 84\n---[ end trace 40412246357cc9e0 ]---\n\ndlm: 59f24629-ae39-44e2-9030-397ebc2eda26: leaving the lockspace group...\nbug: unable to handle kernel null pointer dereference at 0000000000000001\nip: [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140\npgd 0\noops: 0000 [#1] smp\nmodules linked in: dlm 8021q garp mrp stp llc openvswitch nf_defrag_ipv6\nnf_conntrack libcrc32c iptable_filter dm_multipath crc32_pclmul dm_mod\naesni_intel psmouse aes_x86_64 sg ablk_helper cryptd lrw gf128mul\nglue_helper i2c_piix4 nls_utf8 tpm_tis tpm isofs nfsd auth_rpcgss\noid_registry nfs_acl lockd grace sunrpc xen_wdt ip_tables x_tables autofs4\nhid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi 8139too\nserio_raw ata_piix 8139cp mii uhci_hcd ehci_pci ehci_hcd libata\nscsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_mod ipv6\ncpu: 0 pid: 394 comm: systemd-udevd tainted: g w 4.4.0+0 #1\nhardware name: xen hvm domu, bios 4.7.2-2.2 05/11/2017\ntask: ffff880002410000 ti: ffff88000243c000 task.ti: ffff88000243c000\nrip: e030:[<ffffffff811a3b4a>] [<ffffffff811a3b4a>]\nkmem_cache_alloc+0x7a/0x140\nrsp: e02b:ffff88000243fd90 eflags: 00010202\nrax: 0000000000000000 rbx: ffff8800029864d0 rcx: 000000000007b36c\nrdx: 000000000007b36b rsi: 00000000024000c0 rdi: ffff880036801c00\nrbp: ffff88000243fdc0 r08: 0000000000018880 r09: 0000000000000054\nr10: 000000000000004a r11: ffff880034ace6c0 r12: 00000000024000c0\nr13: ffff880036801c00 r14: 0000000000000001 r15: ffffffff8118dcc2\nfs: 00007f0ab77548c0(0000) gs:ffff880036e00000(0000) knlgs:0000000000000000\ncs: e033 ds: 0000 es: 0000 cr0: 0000000080050033\ncr2: 0000000000000001 cr3: 000000000332d000 cr4: 0000000000040660\nstack:\nffffffff8118dc90 ffff8800029864d0 0000000000000000 ffff88003430b0b0\nffff880034b78320 ffff88003430b0b0 ffff88000243fdf8 ffffffff8118dcc2\nffff8800349c6700 ffff8800029864d0 000000000000000b 00007f0ab7754b90\ncall trace:\n[<ffffffff8118dc90>] ? anon_vma_fork+0x60/0x140\n[<ffffffff8118dcc2>] anon_vma_fork+0x92/0x140\n[<ffffffff8107033e>] copy_process+0xcae/0x1a80\n[<ffffffff8107128b>] _do_fork+0x8b/0x2d0\n[<ffffffff81071579>] sys_clone+0x19/0x20\n[<ffffffff815a30ae>] entry_syscall_64_fastpath+0x12/0x71\n] code: f6 75 1c 4c 89 fa 44 89 e6 4c 89 ef e8 a7 e4 00 00 41 f7 c4 00 80\n00 00 49 89 c6 74 47 eb 32 49 63 45 20 48 8d 4a 01 4d 8b 45 00 <49> 8b 1c\n06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 ac 49 63\nrip [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140\nrsp <ffff88000243fd90>\ncr2: 0000000000000001\n--[ end trace 70cb9fd1b164a0e8 ]--\n\nSigned-off-by: Edwin Török <edvin.torok@citrix.com>\nSigned-off-by: David Teigland <teigland@redhat.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/d06189473cae286a6588e28f8baa101ebe799b37"},{"sha":"4fe99d0aad2886f1d3d6b2135821d31ba3ea41b7","author":{"name":"Andy Lutomirski","email":"3cb7d5a8804519b67b2d7945dee31e85c91c02f9@kernel.org"},"message":"x86/fsgsbase/64: Report FSBASE and GSBASE correctly in core dumps\n\ncommit 9584d98bed7a7a904d0702ad06bbcc94703cb5b4 upstream.\n\nIn ELF_COPY_CORE_REGS, we're copying from the current task, so\naccessing thread.fsbase and thread.gsbase makes no sense.  Just read\nthe values from the CPU registers.\n\nIn practice, the old code would have been correct most of the time\nsimply because thread.fsbase and thread.gsbase usually matched the\nCPU registers.\n\nSigned-off-by: Andy Lutomirski <luto@kernel.org>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Borislav Petkov <bpetkov@suse.de>\nCc: Brian Gerst <brgerst@gmail.com>\nCc: Chang Seok <chang.seok.bae@intel.com>\nCc: Denys Vlasenko <dvlasenk@redhat.com>\nCc: H. Peter Anvin <hpa@zytor.com>\nCc: Josh Poimboeuf <jpoimboe@redhat.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/4fe99d0aad2886f1d3d6b2135821d31ba3ea41b7"},{"sha":"f70239b3495212472828b6fb8b6f1d293ac158ec","author":{"name":"Steffen Maier","email":"654c53488e76faec3e98e87271e048eabb668dc6@linux.vnet.ibm.com"},"message":"scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled\n\ncommit 71b8e45da51a7b64a23378221c0a5868bd79da4f upstream.\n\nSince commit db007fc5e20c (\"[SCSI] Command protection operation\"),\nscsi_eh_prep_cmnd() saves scmd->prot_op and temporarily resets it to\nSCSI_PROT_NORMAL.\nOther FCP LLDDs such as qla2xxx and lpfc shield their queuecommand()\nto only access any of scsi_prot_sg...() if\n(scsi_get_prot_op(cmd) != SCSI_PROT_NORMAL).\n\nDo the same thing for zfcp, which introduced DIX support with\ncommit ef3eb71d8ba4 (\"[SCSI] zfcp: Introduce experimental support for\nDIF/DIX\").\n\nOtherwise, TUR SCSI commands as part of scsi_eh likely fail in zfcp,\nbecause the regular SCSI command with DIX protection data, that scsi_eh\nre-uses in scsi_send_eh_cmnd(), of course still has\n(scsi_prot_sg_count() != 0) and so zfcp sends down bogus requests to the\nFCP channel hardware.\n\nThis causes scsi_eh_test_devices() to have (finish_cmds == 0)\n[not SCSI device is online or not scsi_eh_tur() failed]\nso regular SCSI commands, that caused / were affected by scsi_eh,\nare moved to work_q and scsi_eh_test_devices() itself returns false.\nIn turn, it unnecessarily escalates in our case in scsi_eh_ready_devs()\nbeyond host reset to finally scsi_eh_offline_sdevs()\nwhich sets affected SCSI devices offline with the following kernel message:\n\n\"kernel: sd H:0:T:L: Device offlined - not ready after error recovery\"\n\nSigned-off-by: Steffen Maier <maier@linux.vnet.ibm.com>\nFixes: ef3eb71d8ba4 (\"[SCSI] zfcp: Introduce experimental support for DIF/DIX\")\nReviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/f70239b3495212472828b6fb8b6f1d293ac158ec"},{"sha":"a5f62a9212cd9f447193da57feba524b4c843f07","author":{"name":"Benjamin Block","email":"553b4397949a14f52c52f5b1effb37495190d620@linux.vnet.ibm.com"},"message":"scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path\n\ncommit a099b7b1fc1f0418ab8d79ecf98153e1e134656e upstream.\n\nUp until now zfcp would just ignore the FCP_RESID_OVER flag in the FCP\nresponse IU. When this flag is set, it is possible, in regards to the\nFCP standard, that the storage-server processes the command normally, up\nto the point where data is missing and simply ignores those.\n\nIn this case no CHECK CONDITION would be set, and because we ignored the\nFCP_RESID_OVER flag we resulted in at least a data loss or even\n-corruption as a follow-up error, depending on how the\napplications/layers on top behave. To prevent this, we now set the\nhost-byte of the corresponding scsi_cmnd to DID_ERROR.\n\nOther storage-behaviors, where the same condition results in a CHECK\nCONDITION set in the answer, don't need to be changed as they are\nhandled in the mid-layer already.\n\nFollowing is an example trace record decoded with zfcpdbf from the\ns390-tools package. We forcefully injected a fc_dl which is one byte too\nsmall:\n\nTimestamp      : ...\nArea           : SCSI\nSubarea        : 00\nLevel          : 3\nException      : -\nCPU ID         : ..\nCaller         : 0x...\nRecord ID      : 1\nTag            : rsl_err\nRequest ID     : 0x...\nSCSI ID        : 0x...\nSCSI LUN       : 0x...\nSCSI result    : 0x00070000\n                     ^^DID_ERROR\nSCSI retries   : 0x..\nSCSI allowed   : 0x..\nSCSI scribble  : 0x...\nSCSI opcode    : 2a000000 00000000 08000000 00000000\nFCP rsp inf cod: 0x00\nFCP rsp IU     : 00000000 00000000 00000400 00000001\n                                       ^^fr_flags==FCP_RESID_OVER\n                                         ^^fr_status==SAM_STAT_GOOD\n                                            ^^^^^^^^fr_resid\n                 00000000 00000000\n\nAs of now, we don't actively handle to possibility that a response IU\nhas both flags - FCP_RESID_OVER and FCP_RESID_UNDER - set at once.\n\nReported-by: Luke M. Hopkins <lmhopkin@us.ibm.com>\nReviewed-by: Steffen Maier <maier@linux.vnet.ibm.com>\nFixes: 553448f6c483 (\"[SCSI] zfcp: Message cleanup\")\nFixes: ea127f975424 (\"[PATCH] s390 (7/7): zfcp host adapter.\") (tglx/history.git)\nSigned-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/a5f62a9212cd9f447193da57feba524b4c843f07"},{"sha":"0ad9409e45b50b9eb971f495db57a95b8c4cf0f2","author":{"name":"Steffen Maier","email":"654c53488e76faec3e98e87271e048eabb668dc6@linux.vnet.ibm.com"},"message":"scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records\n\ncommit 975171b4461be296a35e83ebd748946b81cf0635 upstream.\n\nv4.9 commit aceeffbb59bb (\"zfcp: trace full payload of all SAN records\n(req,resp,iels)\") fixed trace data loss of 2.6.38 commit 2c55b750a884\n(\"[SCSI] zfcp: Redesign of the debug tracing for SAN records.\")\nnecessary for problem determination, e.g. to see the\ncurrently active zone set during automatic port scan.\n\nWhile it already saves space by not dumping any empty residual entries\nof the large successful GPN_FT response (4 pages), there are seldom cases\nwhere the GPN_FT response is unsuccessful and likely does not have\nFC_NS_FID_LAST set in fp_flags so we did not cap the trace record.\nWe typically see such case for an initiator WWPN, which is not in any zone.\n\nCap unsuccessful responses to at least the actual basic CT_IU response\nplus whatever fits the SAN trace record built-in \"payload\" buffer\njust in case there's trailing information\nof which we would at least see the existence and its beginning.\n\nIn order not to erroneously cap successful responses, we need to swap\ncalling the trace function and setting the CT / ELS status to success (0).\n\nExample trace record pair formatted with zfcpdbf:\n\nTimestamp      : ...\nArea           : SAN\nSubarea        : 00\nLevel          : 1\nException      : -\nCPU ID         : ..\nCaller         : 0x...\nRecord ID      : 1\nTag            : fssct_1\nRequest ID     : 0x<request_id>\nDestination ID : 0x00fffffc\nSAN req short  : 01000000 fc020000 01720ffc 00000000\n                 00000008\nSAN req length : 20\n|\nTimestamp      : ...\nArea           : SAN\nSubarea        : 00\nLevel          : 1\nException      : -\nCPU ID         : ..\nCaller         : 0x...\nRecord ID      : 2\nTag            : fsscth2\nRequest ID     : 0x<request_id>\nDestination ID : 0x00fffffc\nSAN resp short : 01000000 fc020000 80010000 00090700\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\nSAN resp length: 16384\nSan resp info  : 01000000 fc020000 80010000 00090700\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n                 00000000 00000000 00000000 00000000 [trailing info]\n\nThe fix saves all but one of the previously associated 64 PAYload trace\nrecord chunks of size 256 bytes each.\n\nSigned-off-by: Steffen Maier <maier@linux.vnet.ibm.com>\nFixes: aceeffbb59bb (\"zfcp: trace full payload of all SAN records (req,resp,iels)\")\nFixes: 2c55b750a884 (\"[SCSI] zfcp: Redesign of the debug tracing for SAN records.\")\nReviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/0ad9409e45b50b9eb971f495db57a95b8c4cf0f2"},{"sha":"575864f93bda010b168bab0114f9bb617566e0ce","author":{"name":"Steffen Maier","email":"654c53488e76faec3e98e87271e048eabb668dc6@linux.vnet.ibm.com"},"message":"scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA\n\ncommit 9fe5d2b2fd30aa8c7827ec62cbbe6d30df4fe3e3 upstream.\n\nWithout this fix we get SCSI trace records on task management functions\nwhich cannot be correlated to HBA trace records because all fields\nrelated to the FSF request are empty (zero).\nAlso, the FCP_RSP_IU is missing as well as any sense data if available.\n\nThis was caused by v2.6.14 commit 8a36e4532ea1 (\"[SCSI] zfcp: enhancement\nof zfcp debug features\") introducing trace records for TMFs but\nhard coding NULL for a possibly existing TMF FSF request.\nThe scsi_cmnd scribble is also zero or unrelated for the TMF request\nso it also could not lookup a suitable FSF request from there.\n\nA broken example trace record formatted with zfcpdbf from the s390-tools\npackage:\n\nTimestamp      : ...\nArea           : SCSI\nSubarea        : 00\nLevel          : 1\nException      : -\nCPU ID         : ..\nCaller         : 0x...\nRecord ID      : 1\nTag            : lr_fail\nRequest ID     : 0x0000000000000000\n                   ^^^^^^^^^^^^^^^^ no correlation to HBA record\nSCSI ID        : 0x<scsitarget>\nSCSI LUN       : 0x<scsilun>\nSCSI result    : 0x000e0000\nSCSI retries   : 0x00\nSCSI allowed   : 0x05\nSCSI scribble  : 0x0000000000000000\nSCSI opcode    : 2a000017 3bb80000 08000000 00000000\nFCP rsp inf cod: 0x00\n                   ^^ no TMF response\nFCP rsp IU     : 00000000 00000000 00000000 00000000\n                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n                 00000000 00000000\n                 ^^^^^^^^^^^^^^^^^ no interesting FCP_RSP_IU\nSense len      : ...\n^^^^^^^^^^^^^^^^^^^^ no sense data length\nSense info     : ...\n^^^^^^^^^^^^^^^^^^^^ no sense data content, even if present\n\nThere are some true cases where we really do not have an FSF request:\n\"rsl_fai\" from zfcp_dbf_scsi_fail_send() called for early\nreturns / completions in zfcp_scsi_queuecommand(),\n\"abrt_or\", \"abrt_bl\", \"abrt_ru\", \"abrt_ar\" from\nzfcp_scsi_eh_abort_handler() where we did not get as far,\n\"lr_nres\", \"tr_nres\" from zfcp_task_mgmt_function() where we're\nsuccessful and do not need to do anything because adapter stopped.\nFor these cases it's correct to pass NULL for fsf_req to _zfcp_dbf_scsi().\n\nSigned-off-by: Steffen Maier <maier@linux.vnet.ibm.com>\nFixes: 8a36e4532ea1 (\"[SCSI] zfcp: enhancement of zfcp debug features\")\nReviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/575864f93bda010b168bab0114f9bb617566e0ce"},{"sha":"78b8fbf4fc51ce2d8aac4d1b12e77d8fd19dfebf","author":{"name":"Steffen Maier","email":"654c53488e76faec3e98e87271e048eabb668dc6@linux.vnet.ibm.com"},"message":"scsi: zfcp: fix missing trace records for early returns in TMF eh handlers\n\ncommit 1a5d999ebfc7bfe28deb48931bb57faa8e4102b6 upstream.\n\nFor problem determination we need to see that we were in scsi_eh\nas well as whether and why we were successful or not.\n\nThe following commits introduced new early returns without adding\na trace record:\n\nv2.6.35 commit a1dbfddd02d2\n(\"[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh\")\non fc_block_scsi_eh() returning != 0 which is FAST_IO_FAIL,\n\nv2.6.30 commit 63caf367e1c9\n(\"[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp\")\non not having gotten an FSF request after the maximum number of retry\nattempts and thus could not issue a TMF and has to return FAILED.\n\nSigned-off-by: Steffen Maier <maier@linux.vnet.ibm.com>\nFixes: a1dbfddd02d2 (\"[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh\")\nFixes: 63caf367e1c9 (\"[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp\")\nReviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/78b8fbf4fc51ce2d8aac4d1b12e77d8fd19dfebf"},{"sha":"6c39dd63a30093a57f03f5fcf3ccf9b41fdeb5e1","author":{"name":"Steffen Maier","email":"654c53488e76faec3e98e87271e048eabb668dc6@linux.vnet.ibm.com"},"message":"scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records\n\ncommit 12c3e5754c8022a4f2fd1e9f00d19e99ee0d3cc1 upstream.\n\nIf the FCP_RSP UI has optional parts (FCP_SNS_INFO or FCP_RSP_INFO) and\nthus does not fit into the fsp_rsp field built into a SCSI trace record,\ntrace the full FCP_RSP UI with all optional parts as payload record\ninstead of just FCP_SNS_INFO as payload and\na 1 byte RSP_INFO_CODE part of FCP_RSP_INFO built into the SCSI record.\n\nThat way we would also get the full FCP_SNS_INFO in case a\ntarget would ever send more than\nmin(SCSI_SENSE_BUFFERSIZE==96, ZFCP_DBF_PAY_MAX_REC==256)==96.\n\nThe mandatory part of FCP_RSP IU is only 24 bytes.\nPAYload costs at least one full PAY record of 256 bytes anyway.\nWe cap to the hardware response size which is only FSF_FCP_RSP_SIZE==128.\nSo we can just put the whole FCP_RSP IU with any optional parts into\nPAYload similarly as we do for SAN PAY since v4.9 commit aceeffbb59bb\n(\"zfcp: trace full payload of all SAN records (req,resp,iels)\").\nThis does not cause any additional trace records wasting memory.\n\nDecoded trace records were confusing because they showed a hard-coded\nsense data length of 96 even if the FCP_RSP_IU field FCP_SNS_LEN showed\nactually less.\n\nSince the same commit, we set pl_len for SAN traces to the full length of a\nrequest/response even if we cap the corresponding trace.\nIn contrast, here for SCSI traces we set pl_len to the pre-computed\nlength of FCP_RSP IU considering SNS_LEN or RSP_LEN if valid.\nNonetheless we trace a hardcoded payload of length FSF_FCP_RSP_SIZE==128\nif there were optional parts.\nThis makes it easier for the zfcpdbf tool to format only the relevant\npart of the long FCP_RSP UI buffer. And any trailing information is still\navailable in the payload trace record just in case.\n\nRename the payload record tag from \"fcp_sns\" to \"fcp_riu\" to make the new\ncontent explicit to zfcpdbf which can then pick a suitable field name such\nas \"FCP rsp IU all:\" instead of \"Sense info :\"\nAlso, the same zfcpdbf can still be backwards compatible with \"fcp_sns\".\n\nOld example trace record before this fix, formatted with the tool zfcpdbf\nfrom s390-tools:\n\nTimestamp      : ...\nArea           : SCSI\nSubarea        : 00\nLevel          : 3\nException      : -\nCPU id         : ..\nCaller         : 0x...\nRecord id      : 1\nTag            : rsl_err\nRequest id     : 0x<request_id>\nSCSI ID        : 0x...\nSCSI LUN       : 0x...\nSCSI result    : 0x00000002\nSCSI retries   : 0x00\nSCSI allowed   : 0x05\nSCSI scribble  : 0x<request_id>\nSCSI opcode    : 00000000 00000000 00000000 00000000\nFCP rsp inf cod: 0x00\nFCP rsp IU     : 00000000 00000000 00000202 00000000\n                                       ^^==FCP_SNS_LEN_VALID\n                 00000020 00000000\n                 ^^^^^^^^==FCP_SNS_LEN==32\nSense len      : 96 <==min(SCSI_SENSE_BUFFERSIZE,ZFCP_DBF_PAY_MAX_REC)\nSense info     : 70000600 00000018 00000000 29000000\n                 00000400 00000000 00000000 00000000\n                 00000000 00000000 00000000 00000000<==superfluous\n                 00000000 00000000 00000000 00000000<==superfluous\n                 00000000 00000000 00000000 00000000<==superfluous\n                 00000000 00000000 00000000 00000000<==superfluous\n\nNew example trace records with this fix:\n\nTimestamp      : ...\nArea           : SCSI\nSubarea        : 00\nLevel          : 3\nException      : -\nCPU ID         : ..\nCaller         : 0x...\nRecord ID      : 1\nTag            : rsl_err\nRequest ID     : 0x<request_id>\nSCSI ID        : 0x...\nSCSI LUN       : 0x...\nSCSI result    : 0x00000002\nSCSI retries   : 0x00\nSCSI allowed   : 0x03\nSCSI scribble  : 0x<request_id>\nSCSI opcode    : a30c0112 00000000 02000000 00000000\nFCP rsp inf cod: 0x00\nFCP rsp IU     : 00000000 00000000 00000a02 00000200\n                 00000020 00000000\nFCP rsp IU len : 56\nFCP rsp IU all : 00000000 00000000 00000a02 00000200\n                                       ^^=FCP_RESID_UNDER|FCP_SNS_LEN_VALID\n                 00000020 00000000 70000500 00000018\n                 ^^^^^^^^==FCP_SNS_LEN\n                                   ^^^^^^^^^^^^^^^^^\n                 00000000 240000cb 00011100 00000000\n                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n                 00000000 00000000\n                 ^^^^^^^^^^^^^^^^^==FCP_SNS_INFO\n\nTimestamp      : ...\nArea           : SCSI\nSubarea        : 00\nLevel          : 1\nException      : -\nCPU ID         : ..\nCaller         : 0x...\nRecord ID      : 1\nTag            : lr_okay\nRequest ID     : 0x<request_id>\nSCSI ID        : 0x...\nSCSI LUN       : 0x...\nSCSI result    : 0x00000000\nSCSI retries   : 0x00\nSCSI allowed   : 0x05\nSCSI scribble  : 0x<request_id>\nSCSI opcode    : <CDB of unrelated SCSI command passed to eh handler>\nFCP rsp inf cod: 0x00\nFCP rsp IU     : 00000000 00000000 00000100 00000000\n                 00000000 00000008\nFCP rsp IU len : 32\nFCP rsp IU all : 00000000 00000000 00000100 00000000\n                                       ^^==FCP_RSP_LEN_VALID\n                 00000000 00000008 00000000 00000000\n                          ^^^^^^^^==FCP_RSP_LEN\n                                   ^^^^^^^^^^^^^^^^^==FCP_RSP_INFO\n\nSigned-off-by: Steffen Maier <maier@linux.vnet.ibm.com>\nFixes: 250a1352b95e (\"[SCSI] zfcp: Redesign of the debug tracing for SCSI records.\")\nReviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/6c39dd63a30093a57f03f5fcf3ccf9b41fdeb5e1"},{"sha":"b467649e33ec97a1956c2038bb43e317f32a9911","author":{"name":"Steffen Maier","email":"654c53488e76faec3e98e87271e048eabb668dc6@linux.vnet.ibm.com"},"message":"scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response\n\ncommit fdb7cee3b9e3c561502e58137a837341f10cbf8b upstream.\n\nAt the default trace level, we only trace unsuccessful events including\nFSF responses.\n\nzfcp_dbf_hba_fsf_response() only used protocol status and FSF status to\ndecide on an unsuccessful response. However, this is only one of multiple\npossible sources determining a failed struct zfcp_fsf_req.\n\nAn FSF request can also \"fail\" if its response runs into an ERP timeout\nor if it gets dismissed because a higher level recovery was triggered\n[trace tags \"erscf_1\" or \"erscf_2\" in zfcp_erp_strategy_check_fsfreq()].\nFSF requests with ERP timeout are:\nFSF_QTCB_EXCHANGE_CONFIG_DATA, FSF_QTCB_EXCHANGE_PORT_DATA,\nFSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT or\nFSF_QTCB_CLOSE_PHYSICAL_PORT for target ports,\nFSF_QTCB_OPEN_LUN, FSF_QTCB_CLOSE_LUN.\nOne example is slow queue processing which can cause follow-on errors,\ne.g. FSF_PORT_ALREADY_OPEN after FSF_QTCB_OPEN_PORT_WITH_DID timed out.\nIn order to see the root cause, we need to see late responses even if the\nchannel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.\nExample trace records formatted with zfcpdbf from the s390-tools package:\n\nTimestamp      : ...\nArea           : REC\nSubarea        : 00\nLevel          : 1\nException      : -\nCPU ID         : ..\nCaller         : ...\nRecord ID      : 1\nTag            : fcegpf1\nLUN            : 0xffffffffffffffff\nWWPN           : 0x<WWPN>\nD_ID           : 0x00<D_ID>\nAdapter status : 0x5400050b\nPort status    : 0x41200000\nLUN status     : 0x00000000\nReady count    : 0x00000001\nRunning count  : 0x...\nERP want       : 0x02\t\t\t\tZFCP_ERP_ACTION_REOPEN_PORT\nERP need       : 0x02\t\t\t\tZFCP_ERP_ACTION_REOPEN_PORT\n|\nTimestamp      : ...\t\t\t\t30 seconds later\nArea           : REC\nSubarea        : 00\nLevel          : 1\nException      : -\nCPU ID         : ..\nCaller         : ...\nRecord ID      : 2\nTag            : erscf_2\nLUN            : 0xffffffffffffffff\nWWPN           : 0x<WWPN>\nD_ID           : 0x00<D_ID>\nAdapter status : 0x5400050b\nPort status    : 0x41200000\nLUN status     : 0x00000000\nRequest ID     : 0x<request_ID>\nERP status     : 0x10000000\t\t\tZFCP_STATUS_ERP_TIMEDOUT\nERP step       : 0x0800\t\t\t\tZFCP_ERP_STEP_PORT_OPENING\nERP action     : 0x02\t\t\t\tZFCP_ERP_ACTION_REOPEN_PORT\nERP count      : 0x00\n|\nTimestamp      : ...\t\t\t\tlater than previous record\nArea           : HBA\nSubarea        : 00\nLevel          : 5\t> default level\t\t=> 3\t<= default level\nException      : -\nCPU ID         : 00\nCaller         : ...\nRecord ID      : 1\nTag            : fs_qtcb\t\t\t=> fs_rerr\nRequest ID     : 0x<request_ID>\nRequest status : 0x00001010\t\t\tZFCP_STATUS_FSFREQ_DISMISSED\n\t\t\t\t\t\t| ZFCP_STATUS_FSFREQ_CLEANUP\nFSF cmnd       : 0x00000005\nFSF sequence no: 0x...\nFSF issued     : ...\t\t\t\t> 30 seconds ago\nFSF stat       : 0x00000000\t\t\tFSF_GOOD\nFSF stat qual  : 00000000 00000000 00000000 00000000\nProt stat      : 0x00000001\t\t\tFSF_PROT_GOOD\nProt stat qual : 00000000 00000000 00000000 00000000\nPort handle    : 0x...\nLUN handle     : 0x00000000\nQTCB log length: ...\nQTCB log info  : ...\n\nIn case of problems detecting that new responses are waiting on the input\nqueue, we sooner or later trigger adapter recovery due to an FSF request\ntimeout (trace tag \"fsrth_1\").\nFSF requests with FSF request timeout are:\ntypically FSF_QTCB_ABORT_FCP_CMND; but theoretically also\nFSF_QTCB_EXCHANGE_CONFIG_DATA or FSF_QTCB_EXCHANGE_PORT_DATA via sysfs,\nFSF_QTCB_OPEN_PORT_WITH_DID or FSF_QTCB_CLOSE_PORT for WKA ports,\nFSF_QTCB_FCP_CMND for task management function (LUN / target reset).\nOne or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD\nbecause the channel filled in the response via DMA into the request's QTCB.\n\nIn a theroretical case, inject code can create an erroneous FSF request\non purpose. If data router is enabled, it uses deferred error reporting.\nA READ SCSI command can succeed with FSF_PROT_GOOD, FSF_GOOD, and\nSAM_STAT_GOOD. But on writing the read data to host memory via DMA,\nit can still fail, e.g. if an intentionally wrong scatter list does not\nprovide enough space. Rather than getting an unsuccessful response,\nwe get a QDIO activate check which in turn triggers adapter recovery.\nOne or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD\nbecause the channel filled in the response via DMA into the request's QTCB.\nExample trace records formatted with zfcpdbf from the s390-tools package:\n\nTimestamp      : ...\nArea           : HBA\nSubarea        : 00\nLevel          : 6\t> default level\t\t=> 3\t<= default level\nException      : -\nCPU ID         : ..\nCaller         : ...\nRecord ID      : 1\nTag            : fs_norm\t\t\t=> fs_rerr\nRequest ID     : 0x<request_ID2>\nRequest status : 0x00001010\t\t\tZFCP_STATUS_FSFREQ_DISMISSED\n\t\t\t\t\t\t| ZFCP_STATUS_FSFREQ_CLEANUP\nFSF cmnd       : 0x00000001\nFSF sequence no: 0x...\nFSF issued     : ...\nFSF stat       : 0x00000000\t\t\tFSF_GOOD\nFSF stat qual  : 00000000 00000000 00000000 00000000\nProt stat      : 0x00000001\t\t\tFSF_PROT_GOOD\nProt stat qual : ........ ........ 00000000 00000000\nPort handle    : 0x...\nLUN handle     : 0x...\n|\nTimestamp      : ...\nArea           : SCSI\nSubarea        : 00\nLevel          : 3\nException      : -\nCPU ID         : ..\nCaller         : ...\nRecord ID      : 1\nTag            : rsl_err\nRequest ID     : 0x<request_ID2>\nSCSI ID        : 0x...\nSCSI LUN       : 0x...\nSCSI result    : 0x000e0000\t\t\tDID_TRANSPORT_DISRUPTED\nSCSI retries   : 0x00\nSCSI allowed   : 0x05\nSCSI scribble  : 0x<request_ID2>\nSCSI opcode    : 28...\t\t\t\tRead(10)\nFCP rsp inf cod: 0x00\nFCP rsp IU     : 00000000 00000000 00000000 00000000\n                                         ^^\tSAM_STAT_GOOD\n                 00000000 00000000\n\nOnly with luck in both above cases, we could see a follow-on trace record\nof an unsuccesful event following a successful but late FSF response with\nFSF_PROT_GOOD and FSF_GOOD. Typically this was the case for I/O requests\nresulting in a SCSI trace record \"rsl_err\" with DID_TRANSPORT_DISRUPTED\n[On ZFCP_STATUS_FSFREQ_DISMISSED, zfcp_fsf_protstatus_eval() sets\nZFCP_STATUS_FSFREQ_ERROR seen by the request handler functions as failure].\nHowever, the reason for this follow-on trace was invisible because the\ncorresponding HBA trace record was missing at the default trace level\n(by default hidden records with tags \"fs_norm\", \"fs_qtcb\", or \"fs_open\").\n\nOn adapter recovery, after we had shut down the QDIO queues, we perform\nunsuccessful pseudo completions with flag ZFCP_STATUS_FSFREQ_DISMISSED\nfor each pending FSF request in zfcp_fsf_req_dismiss_all().\nIn order to find the root cause, we need to see all pseudo responses even\nif the channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.\n\nTherefore, check zfcp_fsf_req.status for ZFCP_STATUS_FSFREQ_DISMISSED\nor ZFCP_STATUS_FSFREQ_ERROR and trace with a new tag \"fs_rerr\".\n\nIt does not matter that there are numerous places which set\nZFCP_STATUS_FSFREQ_ERROR after the location where we trace an FSF response\nearly. These cases are based on protocol status != FSF_PROT_GOOD or\n== FSF_PROT_FSF_STATUS_PRESENTED and are thus already traced by default\nas trace tag \"fs_perr\" or \"fs_ferr\" respectively.\n\nNB: The trace record with tag \"fssrh_1\" for status read buffers on dismiss\nall remains. zfcp_fsf_req_complete() handles this and returns early.\nAll other FSF request types are handled separately and as described above.\n\nSigned-off-by: Steffen Maier <maier@linux.vnet.ibm.com>\nFixes: 8a36e4532ea1 (\"[SCSI] zfcp: enhancement of zfcp debug features\")\nFixes: 2e261af84cdb (\"[SCSI] zfcp: Only collect FSF/HBA debug data for matching trace levels\")\nReviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/b467649e33ec97a1956c2038bb43e317f32a9911"},{"sha":"af8bbadc62b289fd658e56b02ecdefd808c4ddff","author":{"name":"Finn Thain","email":"86b390fcaaea23e6369bd6b019cb5ffd1fadc018@telegraphics.com.au"},"message":"scsi: mac_esp: Fix PIO transfers for MESSAGE IN phase\n\ncommit 7640d91d285893a5cf1e62b2cd00f0884c401d93 upstream.\n\nWhen in MESSAGE IN phase, the ESP device does not automatically\nacknowledge each byte that is transferred by PIO. The mac_esp driver\nneglects to explicitly ack them, which causes a timeout during messages\nlarger than one byte (e.g. tag bytes during reconnect). Fix this with an\nESP_CMD_MOK command after each byte.\n\nThe MESSAGE IN phase is also different in that each byte transferred\nraises ESP_INTR_FDONE. So don't exit the transfer loop for this interrupt,\nfor this phase.\n\nThat resolves the \"Reconnect IRQ2 timeout\" error on those Macs which use\nPIO transfers instead of PDMA. This patch also improves on the weak tests\nfor unexpected interrupts and phase changes during PIO transfers.\n\nTested-by: Stan Johnson <userm57@yahoo.com>\nFixes: 02507a80b35e (\"[PATCH] [SCSI] mac_esp: fix PIO mode, take 2\")\nSigned-off-by: Finn Thain <fthain@telegraphics.com.au>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/af8bbadc62b289fd658e56b02ecdefd808c4ddff"},{"sha":"27c98187446ad56a2911e5c83baf4ebf68492b91","author":{"name":"Andrey Korolyov","email":"cd8c02a38d875582678c1caebf78fdd1bf254a95@xdel.ru"},"message":"cs5536: add support for IDE controller variant\n\ncommit 591b6bb605785c12a21e8b07a08a277065b655a5 upstream.\n\nSeveral legacy devices such as Geode-based Cisco ASA appliances\nand DB800 development board do possess CS5536 IDE controller\nwith different PCI id than existing one. Using pata_generic is\nnot always feasible as at least DB800 requires MSR quirk from\npata_cs5536 to be used with vendor firmware.\n\nSigned-off-by: Andrey Korolyov <andrey@xdel.ru>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/27c98187446ad56a2911e5c83baf4ebf68492b91"},{"sha":"a08789b3fa9475ecfc767aeba88b0f0303459c90","author":{"name":"Xiangliang.Yu","email":"475d75d6a59a5ea22054cec22a039d0901f55941@amd.com"},"message":"drm/ttm: Fix accounting error when fail to get pages for pool\n\ncommit 9afae2719273fa1d406829bf3498f82dbdba71c7 upstream.\n\nWhen fail to get needed page for pool, need to put allocated pages\ninto pool. But current code has a miscalculation of allocated pages,\ncorrect it.\n\nSigned-off-by: Xiangliang.Yu <Xiangliang.Yu@amd.com>\nReviewed-by: Christian König <christian.koenig@amd.com>\nReviewed-by: Monk Liu <monk.liu@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/a08789b3fa9475ecfc767aeba88b0f0303459c90"},{"sha":"e813577167c4a1c3f25cd9d84c29301b82d95597","author":{"name":"Bart Van Assche","email":"b8a13ad2fc8473e67a34a68acf4216fb1fa3477b@wdc.com"},"message":"block: Relax a check in blk_start_queue()\n\ncommit 4ddd56b003f251091a67c15ae3fe4a5c5c5e390a upstream.\n\nCalling blk_start_queue() from interrupt context with the queue\nlock held and without disabling IRQs, as the skd driver does, is\nsafe. This patch avoids that loading the skd driver triggers the\nfollowing warning:\n\nWARNING: CPU: 11 PID: 1348 at block/blk-core.c:283 blk_start_queue+0x84/0xa0\nRIP: 0010:blk_start_queue+0x84/0xa0\nCall Trace:\n skd_unquiesce_dev+0x12a/0x1d0 [skd]\n skd_complete_internal+0x1e7/0x5a0 [skd]\n skd_complete_other+0xc2/0xd0 [skd]\n skd_isr_completion_posted.isra.30+0x2a5/0x470 [skd]\n skd_isr+0x14f/0x180 [skd]\n irq_forced_thread_fn+0x2a/0x70\n irq_thread+0x144/0x1a0\n kthread+0x125/0x140\n ret_from_fork+0x2a/0x40\n\nFixes: commit a038e2536472 (\"[PATCH] blk_start_queue() must be called with irq disabled - add warning\")\nSigned-off-by: Bart Van Assche <bart.vanassche@wdc.com>\nCc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>\nCc: Andrew Morton <akpm@osdl.org>\nCc: Christoph Hellwig <hch@lst.de>\nCc: Hannes Reinecke <hare@suse.de>\nCc: Johannes Thumshirn <jthumshirn@suse.de>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/e813577167c4a1c3f25cd9d84c29301b82d95597"},{"sha":"c889e4cbe9b3975b3f8d109c397b0b8ef2d7bd2f","author":{"name":"Guenter Roeck","email":"177f6c7e7d0681e1b64ab10ef561094344edf6d6@roeck-us.net"},"message":"media: uvcvideo: Prevent heap overflow when accessing mapped controls\n\ncommit 7e09f7d5c790278ab98e5f2c22307ebe8ad6e8ba upstream.\n\nThe size of uvc_control_mapping is user controlled leading to a\npotential heap overflow in the uvc driver. This adds a check to verify\nthe user provided size fits within the bounds of the defined buffer\nsize.\n\nOriginally-from: Richard Simmons <rssimmo@amazon.com>\n\nSigned-off-by: Guenter Roeck <linux@roeck-us.net>\nReviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\nSigned-off-by: Hans Verkuil <hans.verkuil@cisco.com>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>\n[bwh: Backported to 3.2: adjust filename]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/c889e4cbe9b3975b3f8d109c397b0b8ef2d7bd2f"},{"sha":"f9f71f3a1e4f36cd4c3493003eb9a0c5c234ca52","author":{"name":"Sean Young","email":"745a5948f3a29be7b294faa8063f9998c214afbb@mess.org"},"message":"media: lirc_zilog: driver only sends LIRCCODE\n\ncommit 89d8a2cc51d1f29ea24a0b44dde13253141190a0 upstream.\n\nThis driver cannot send pulse, it only accepts driver-dependent codes.\n\nSigned-off-by: Sean Young <sean@mess.org>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","distinct":false,"url":"https://api.github.com/repos/mifl/android_kernel_qcom_msm-3.18/commits/f9f71f3a1e4f36cd4c3493003eb9a0c5c234ca52"}]}
{"actor":{"display_login":"mifl"}}