- 04 Aug, 2013 40 commits
-
-
Jan Beulich authored
commit 093b9c71 upstream. Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure linear area is big enough on RX") xennet_fill_frags() may end up filling MAX_SKB_FRAGS + 1 fragments in a receive skb, and only reduce the fragment count subsequently via __pskb_pull_tail(). That's a result of xennet_get_responses() allowing a maximum of one more slot to be consumed (and intermediately transformed into a fragment) if the head slot has a size less than or equal to RX_COPY_THRESHOLD. Hence we need to adjust xennet_fill_frags() to pull earlier if we reached the maximum fragment count - due to the described behavior of xennet_get_responses() this guarantees that at least the first fragment will get completely consumed, and hence the fragment count reduced. In order to not needlessly call __pskb_pull_tail() twice, make the original call conditional upon the pull target not having been reached yet, and defer the newly added one as much as possible (an alternative would have been to always call the function right before the call to xennet_fill_frags(), but that would imply more frequent cases of needing to call it twice). Signed-off-by:
Jan Beulich <jbeulich@suse.com> Acked-by:
Wei Liu <wei.liu2@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Josef Bacik authored
commit d29a9f62 upstream. If we stop dropping a root for whatever reason we need to add it back to the dead root list so that we will re-start the dropping next transaction commit. The other case this happens is if we recover a drop because we will add a root without adding it to the fs radix tree, so we can leak it's root and commit root extent buffer, adding this to the dead root list makes this cleanup happen. Thanks, Reported-by:
Alex Lyakas <alex.btrfs@zadarastorage.com> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
-
Josef Bacik authored
commit fec386ac upstream. We aren't setting path->locks[level] when we resume a snapshot deletion which means we won't unlock the buffer when we free the path. This causes deadlocks if we happen to re-allocate the block before we've evicted the extent buffer from cache. Thanks, Reported-by:
-
Stefan Behrens authored
commit 115930cb upstream. Miao Xie reported the following issue: The filesystem was corrupted after we did a device replace. Steps to reproduce: # mkfs.btrfs -f -m single -d raid10 <device0>..<device3> # mount <device0> <mnt> # btrfs replace start -rfB 1 <device4> <mnt> # umount <mnt> # btrfsck <device4> The reason for the issue is that we changed the write offset by mistake, introduced by commit 625f1c8d. We read the data from the source device at first, and then write the data into the corresponding place of the new device. In order to implement the "-r" option, the source location is remapped using btrfs_map_block(). The read takes place on the mapped location, and the write needs to take place on the unmapped location. Currently the write is using the mapped location, and this commit changes it back by undoing the change to the write address that the aforementioned commit added by mistake. Reported-by:
Miao Xie <miaox@cn.fujitsu.com> Signed-off-by:
Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by:
-
Dirk Brandewie authored
commit 2134ed4d upstream. Change to using max P-state instead of max turbo P-state. This change resolves two issues. On a quiet system intel_pstate can fail to respond to a load change. On CPU SKUs that have a limited number of P-states and no turbo range intel_pstate fails to select the highest available P-state. This change is suitable for stable v3.9+ References: https://bugzilla.kernel.org/show_bug.cgi?id=59481Reported-and-tested-by:
Arjan van de Ven <arjan@linux.intel.com> Reported-and-tested-by: dsmythies@telus.net Signed-off-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Karlis Ogsts authored
commit 72bb99cf upstream. In the situation that a writer fails to copy data from userspace it will reset the write offset to the value it had before it went to sleep. This discarding any messages written while aquiring the mutex. Therefore the reset offset needs to be retrieved after acquiring the mutex. Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
-
Ian Abbott authored
commit 69acbaac upstream. Comedi devices can do blocking read() or write() (or poll()) if an asynchronous command has been set up, blocking for data (for read()) or buffer space (for write()). Various events associated with the asynchronous command will wake up the blocked reader or writer (or poller). It is also possible to force the asynchronous command to terminate by issuing a `COMEDI_CANCEL` ioctl. That shuts down the asynchronous command, but does not currently wake up the blocked reader or writer (or poller). If the blocked task could be woken up, it would see that the command is no longer active and return. The caller of the `COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by sending a signal, but that's a nasty workaround. Change `do_cancel_ioctl()` to wake up the wait queue after it returns from `do_cancel()`. `do_cancel()` can propagate an error return value from the low-level comedi driver's cancel routine, but it always shuts the command down regardless, so `do_cancel_ioctl()` can wake up he wait queue regardless of the return value from `do_cancel()`. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Ian Abbott authored
commit 4b18f08b upstream. `do_cmd_ioctl()` is called with the comedi device's mutex locked to process the `COMEDI_CMD` ioctl to set up comedi's asynchronous command handling on a comedi subdevice. `comedi_read()` and `comedi_write()` are the `read` and `write` handlers for the comedi device, but do not lock the mutex (for performance reasons, as some things can hold the mutex for quite a long time). There is a race condition if `comedi_read()` or `comedi_write()` is running at the same time and for the same file object and comedi subdevice as `do_cmd_ioctl()`. `do_cmd_ioctl()` sets the subdevice's `busy` pointer to the file object way before it sets the `SRF_RUNNING` flag in the subdevice's `runflags` member. `comedi_read() and `comedi_write()` check the subdevice's `busy` pointer is pointing to the current file object, then if the `SRF_RUNNING` flag is not set, will call `do_become_nonbusy()` to shut down the asyncronous command. Bad things can happen if the asynchronous command is being shutdown and set up at the same time. To prevent the race, don't set the `busy` pointer until after the `SRF_RUNNING` flag has been set. Also, make sure the mutex is held in `comedi_read()` and `comedi_write()` while calling `do_become_nonbusy()` in order to avoid moving the race condition to a point within that function. Change some error handling `goto cleanup` statements in `do_cmd_ioctl()` to simple `return -ERRFOO` statements as a result of changing when the `busy` pointer is set. Signed-off-by:
-
Alan Stern authored
commit e583d9db upstream. The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by:
Toralf Förster <toralf.foerster@gmx.de> Signed-off-by:
-
William Gulland authored
commit 2c7b871b upstream. Control transfers have both IN and OUT (or SETUP) packets, so when clearing TT buffers for a control transfer it's necessary to send two HUB_CLEAR_TT_BUFFER requests to the hub. Signed-off-by:
William Gulland <wgulland@google.com> Acked-by:
-
Jóhann B. Guðmundsson authored
commit 58fc90db upstream. Signed-off-by:
Jóhann B. Guðmundsson <johannbg@fedoraproject.org> Signed-off-by:
-
Johan Hovold authored
commit 1fad5642 upstream. The driver failed to take the dynamic ids into account when determining the device type and therefore all devices were detected as 2-port devices when using the dynamic-id interface. Match on the usb-serial-driver field instead of doing redundant id-table searches. Reported-by:
Anders Hammarquist <iko@iko.pp.se> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Felipe Balbi authored
commit cdcedd69 upstream. In case we fail our ->udc_start() callback, we should be ready to accept another modprobe following the failed one. We had forgotten to clear dwc->gadget_driver back to NULL and, because of that, we were preventing gadget driver modprobe from being retried. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Huang Rui authored
commit 1974d494 upstream. Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the bit is 1, the event is represented Device-Specific Event, then use [7:1] bits as Device Specific Event to marked the type. It has 7 bits, and we can see the reserved8_31 variable name which means from 8 to 31 bits marked reserved, actually there are 24 bits not 25 bits between that. And 1 + 7 + 24 = 32, the event size is 4 byes. So in dwc3_event_type, the bit mask should be: is_devspec [0] 1 bit type [7:1] 7 bits reserved8_31 [31:8] 24 bits This patch should be backported to kernels as old as 3.2, that contain the commit 72246da4 "usb: Introduce DesignWare USB3 DRD Driver". Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Ruchika Kharwar authored
commit 315955d7 upstream. When there is an error with the usb3_phy probe or absence, the error returned is erroneously for usb2_phy. Signed-off-by:
Ruchika Kharwar <ruchika@ti.com> Signed-off-by:
-
Johan Hovold authored
commit 5f8a2e68 upstream. Allocated urbs and buffers were never freed on errors in open. Signed-off-by:
-
Roger Quadros authored
commit 47a64a13 upstream. Set the ehci->resuming flag for the port we receive a remote wakeup on so that resume signalling can be completed. Without this, the root hub timer will not fire again to check if the resume was completed and there will be a never-ending wait on on the port. This effect is only observed if the HUB IRQ IN does not come after we have initiated the port resume. Signed-off-by:
Roger Quadros <rogerq@ti.com> Acked-by:
-
Sarah Sharp authored
commit 203a8661 upstream. When the host controller fails to respond to an Enable Slot command, and the host fails to respond to the register write to abort the command ring, the xHCI driver will assume the host is dead, and call usb_hc_died(). The USB device's slot_id is still set to zero, and the pointer stored at xhci->devs[0] will always be NULL. The call to xhci_check_args in xhci_free_dev should have caught the NULL virt_dev pointer. However, xhci_free_dev is designed to free the xhci_virt_device structures, even if the host is dead, so that we don't leak kernel memory. xhci_free_dev checks the return value from the generic xhci_check_args function. If the return value is -ENODEV, it carries on trying to free the virtual device. The issue is that xhci_check_args looks at the host controller state before it looks at the xhci_virt_device pointer. It will return -ENIVAL because the host is dead, and xhci_free_dev will ignore the return value, and happily dereference the NULL xhci_virt_device pointer. The fix is to make sure that xhci_check_args checks the xhci_virt_device pointer before it checks the host state. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for further details. This patch doesn't solve the underlying issue, but will ensure we don't see any more NULL pointer dereferences because of the issue. This patch should be backported to kernels as old as 3.1, that contain the commit 7bd89b40 "xhci: Don't submit commands or URBs to halted hosts." Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by:
Vincent Thiele <vincentthiele@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
commit d66eaf9f upstream. in some cases where device is attched to xhci port and do not responding, for example ath9k_htc with stalled firmware, kernel will crash on ring_doorbell_for_active_rings. This patch check if pointer exist before it is used. This patch should be backported to kernels as old as 2.6.35, that contain the commit e9df17eb "USB: xhci: Correct assumptions about number of rings per endpoint" Signed-off-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
-
George Cherian authored
commit 07f3cb7c upstream. Xhci controllers with hci_version > 0.96 gives spurious success events on short packet completion. During webcam capture the "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. The same application works fine with synopsis controllers hci_version 0.96. The same issue is seen with Intel Pantherpoint xhci controller. So enabling this quirk in xhci_gen_setup if controller verion is greater than 0.96. For xhci-pci move the quirk to much generic place xhci_gen_setup. Note from Sarah: The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet occurred, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD is not completed until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. It's on my long-term to-do list to fix this race condition, but it is a much more involved patch that will probably be too big for stable. This patch is needed for stable to avoid serious log spam. This patch should be backported to kernels as old as 3.0, that contain the commit ad808333 "Intel xhci: Ignore spurious successful event." The patch will have to be modified for kernels older than 3.2, since that kernel added the xhci_gen_setup function for xhci platform devices. The correct conflict resolution for kernels older than 3.2 is to set XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts. Signed-off-by:
George Cherian <george.cherian@ti.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 09d8091c upstream. Commit a8227415 "tracing: Protect ftrace_trace_arrays list in trace_events.c" added taking the trace_types_lock mutex in trace_events.c as there were several locations that needed it for protection. Unfortunately, it also encapsulated a call to tracing_reset_all_online_cpus() which also takes the trace_types_lock, causing a deadlock. This happens when a module has tracepoints and has been traced. When the module is removed, the trace events module notifier will grab the trace_types_lock, do a bunch of clean ups, and also clears the buffer by calling tracing_reset_all_online_cpus. This doesn't happen often which explains why it wasn't caught right away. Commit a8227415 was marked for stable, which means this must be sent to stable too. Link: http://lkml.kernel.org/r/51EEC646.7070306@broadcom.comReported-by:
Arend van Spril <arend@broadcom.com> Tested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Oleg Nesterov authored
commit e70e78e3 upstream. tracing_buffers_open() does trace_array_get() and then it wrongly inrcements tr->ref again under trace_types_lock. This means that every caller leaks trace_array: # cd /sys/kernel/debug/tracing/ # mkdir instances/X # true < instances/X/per_cpu/cpu0/trace_pipe_raw # rmdir instances/X rmdir: failed to remove `instances/X': Device or resource busy Link: http://lkml.kernel.org/r/20130719153644.GA18899@redhat.comSigned-off-by:
Oleg Nesterov <oleg@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
-
Alexander Z Lam authored
commit f77d09a3 upstream. Some error paths did not handle ref counting properly, and some trace files need ref counting. Link: http://lkml.kernel.org/r/1374171524-11948-1-git-send-email-azl@google.comSigned-off-by:
Alexander Z Lam <azl@google.com> Cc: Vaibhav Nagarnaik <vnagarnaik@google.com> Cc: David Sharp <dhsharp@google.com> Cc: Alexander Z Lam <lambchop468@gmail.com> Signed-off-by:
-
Alexander Z Lam authored
commit 609e85a7 upstream. Remove debugfs directories for tracing instances during creation if an error occurs causing the trace_array for that instance to not be added to ftrace_trace_arrays. If the directory continues to exist after the error, it cannot be removed because the respective trace_array is not in ftrace_trace_arrays. Link: http://lkml.kernel.org/r/1373502874-1706-2-git-send-email-azl@google.comSigned-off-by:
-
Saurav Kashyap authored
commit c3ccb1d7 upstream. This fixes a regression where Xyratex controllers and disks were lost by the driver: https://bugzilla.kernel.org/show_bug.cgi?id=59601Reported-by:
Jack Hill <jackhill@jackhill.us> Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Ewan D. Milne authored
commit 085b513f upstream. sd_prep_fn will allocate a larger CDB for the command via mempool_alloc for devices using DIF type 2 protection. This CDB was being freed in sd_done, which results in a kernel crash if the command is retried due to a UNIT ATTENTION. This change moves the code to free the larger CDB into sd_unprep_fn instead, which is invoked after the request is complete. It is no longer necessary to call scsi_print_command separately for this case as the ->cmnd will no longer be NULL in the normal code path. Also removed conditional test for DIF type 2 when freeing the larger CDB because the protection_type could have been changed via sysfs while the command was executing. Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Jeff Skirvin authored
commit 96f15f29 upstream. This commit fixes a race condition in the isci driver abort task and SSP device task management path. The race is caused when an I/O termination in the SCU hardware is necessary because of an SSP target timeout condition, and the check of the I/O end state races against the HW-termination-driven end state. The failure of the race meant that no TMF was sent to the device to clean-up the pending I/O. Signed-off-by:
Jeff Skirvin <jeffrey.d.skirvin@intel.com> Reviewed-by:
Lukasz Dorau <lukasz.dorau@intel.com> Signed-off-by:
-
Gregory CLEMENT authored
commit faefd550 upstream. When CONFIG_ARM_APPENDED_DTB is selected, if the bootloader provides an ATAG_MEM it replaces the memory size and the memory address in the memory node of the device tree. In the case of a system which can handle more than 4GB, the memory node cell size is 4: each data (memory size and memory address) are 64 bits and then use 2 cells. The current code in atags_to_fdt.c made the assumption of a cell size of 2 (one cell for the memory size and one cell for the memory address), this leads to an improper write of the data and ends with a boot hang. This patch writes the memory size and the memory address on the memory node in the device tree depending of the size of the memory node (32 bits or 64 bits). It has been tested in the 2 cases: - with a dtb using skeleton.dtsi - and with a dtb using skeleton64.dtsi Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Nicolin Chen authored
commit 2e7ee15c upstream. Also fix return values for headphone switch updates. Signed-off-by:
Nicolin Chen <b42378@freescale.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Richard Zhao authored
commit 647ab784 upstream. The errors were caused by copy/paste mistake in below commit since v3.10: 3489d506 ASoC: tegra: Use common DAI DMA data struct It also corrects slave_id initialization in tegra20_ac97 driver. Signed-off-by:
Richard Zhao <rizhao@nvidia.com> Acked-by:
Stephen Warren <swarren@nvidia.com> Acked-by:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
-
Chih-Chung Chang authored
commit cb6f66a2 upstream. The registers of max98088 are 8 bits, not 16 bits. This bug causes the contents of registers to be overwritten with bad values when the codec is suspended and then resumed. Signed-off-by:
Chih-Chung Chang <chihchung@chromium.org> Signed-off-by:
Dylan Reid <dgreid@chromium.org> Signed-off-by:
-
Fabio Estevam authored
commit 016fcab8 upstream. According to the sgtl5000 reference manual, the default value of CHIP_SSS_CTRL is 0x10. Reported-by:
Oskar Schirmer <oskar@scara.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Clemens Ladisch authored
commit 0699a73a upstream. Commit 18d62711 (firewire: prevent dropping of completed iso packet header data) was intended to be an obvious bug fix, but libdc1394 and FlyCap2 depend on the old behaviour by ignoring all returned information and thus not noticing that not all packets have been received yet. The result was that the video frame buffers would be saved before they contained the correct data. Reintroduce the old behaviour for old clients. Tested-by:
Stepan Salenikovich <stepan.salenikovich@gmail.com> Tested-by:
Josep Bosch <jep250@gmail.com> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
David Henningsson authored
commit cd6fb679 upstream. Add two more machines that need quirks for headset mics to work. Tested-by:
Shawn Wang <shawn.wang@canonical.com> BugLink: https://bugs.launchpad.net/bugs/1195636Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
David Henningsson authored
commit 6c29d68a upstream. This quirk is needed for the headset mic to work on this Dell machine. BugLink: https://bugs.launchpad.net/bugs/1195597Signed-off-by:
-
Ren Bigcren authored
commit e7a6121f upstream. The device report an error capacity when read_capacity_16(). Using read_capacity_10() can get the correct capacity. Signed-off-by:
Ren Bigcren <bigcren.ren@sonymobile.com> Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by:
Oskar Andero <oskar.andero@sonymobile.com> Signed-off-by:
-
Nicholas Bellinger authored
commit 186a9647 upstream. This patch adds target_get_sess_cmd reference counting for iscsit_handle_task_mgt_cmd(), and adds a target_put_sess_cmd() for the failure case. It also fixes a bug where ISCSI_OP_SCSI_TMFUNC type commands where leaking iscsi_cmd->i_conn_node and eventually triggering an OOPs during struct isert_conn shutdown. Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit b2cb9649 upstream. This patch addresses a bug where RDMA_CM_EVENT_DISCONNECTED may occur before the connection shutdown has been completed by rx/tx threads, that causes isert_free_conn() to wait indefinately on ->conn_wait. This patch allows isert_disconnect_work code to invoke rdma_disconnect when isert_disconnect_work() process context is started by client session reset before isert_free_conn() code has been reached. It also adds isert_conn->conn_mutex protection for ->state within isert_disconnect_work(), isert_cq_comp_err() and isert_free_conn() code, along with isert_check_state() for wait_event usage. (v2: Add explicit iscsit_cause_connection_reinstatement call during isert_disconnect_work() to force conn reset) Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Joern Engel authored
commit 0fbfc46f upstream. This patch fixes a potential buffer overflow while processing iscsi_node_auth input for configfs attributes within NodeACL tfc_tpg_nacl_auth_cit context. Signed-off-by:
Joern Engel <joern@logfs.org> Signed-off-by:
-
Nicholas Bellinger authored
commit 3df8f68a upstream. This patch adds the missing isert_put_reject() logic to post a outgoing payload buffer to hold the 48 bytes of original PDU header request payload for the rejected cmd. It also fixes ISTATE_SEND_REJECT handling in isert_response_completion() -> isert_do_control_comp() code, and drops incorrect iscsi_cmd_t->reject_comp usage. Signed-off-by:
-
