April 2018 - Linux-stable-mirror

[PATCH v2 01/20] fanotify: fix logic of events on child

by Amir Goldstein

When event on child inodes are sent to the parent inode mark and parent inode mark was not marked with FAN_EVENT_ON_CHILD, the event will not be delivered to the listener process. However, if the same process also has a mount mark, the event to the parent inode will be delivered regadless of the mount mark mask. This behavior is incorrect in the case where the mount mark mask does not contain the specific event type. For example, the process adds a mark on a directory with mask FAN_MODIFY (without FAN_EVENT_ON_CHILD) and a mount mark with mask FAN_CLOSE_NOWRITE (without FAN_ONDIR). A modify event on a file inside that directory (and inside that mount) should not create a FAN_MODIFY event, because neither of the marks requested to get that event on the file. Fixes: 1968f5eed54c ("fanotify: use both marks when possible") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> --- fs/notify/fanotify/fanotify.c | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 6702a6a0bbb5..e0e6a9d627df 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -92,7 +92,7 @@ static bool fanotify_should_send_event(struct fsnotify_mark *inode_mark, u32 event_mask, const void *data, int data_type) { - __u32 marks_mask, marks_ignored_mask; + __u32 marks_mask = 0, marks_ignored_mask = 0; const struct path *path = data; pr_debug("%s: inode_mark=%p vfsmnt_mark=%p mask=%x data=%p" @@ -108,24 +108,20 @@ static bool fanotify_should_send_event(struct fsnotify_mark *inode_mark, !d_can_lookup(path->dentry)) return false; - if (inode_mark && vfsmnt_mark) { - marks_mask = (vfsmnt_mark->mask | inode_mark->mask); - marks_ignored_mask = (vfsmnt_mark->ignored_mask | inode_mark->ignored_mask); - } else if (inode_mark) { - /* - * if the event is for a child and this inode doesn't care about - * events on the child, don't send it! - */ - if ((event_mask & FS_EVENT_ON_CHILD) && - !(inode_mark->mask & FS_EVENT_ON_CHILD)) - return false; - marks_mask = inode_mark->mask; - marks_ignored_mask = inode_mark->ignored_mask; - } else if (vfsmnt_mark) { - marks_mask = vfsmnt_mark->mask; - marks_ignored_mask = vfsmnt_mark->ignored_mask; - } else { - BUG(); + /* + * if the event is for a child and this inode doesn't care about + * events on the child, don't send it! + */ + if (inode_mark && + (!(event_mask & FS_EVENT_ON_CHILD) || + (inode_mark->mask & FS_EVENT_ON_CHILD))) { + marks_mask |= inode_mark->mask; + marks_ignored_mask |= inode_mark->ignored_mask; + } + + if (vfsmnt_mark) { + marks_mask |= vfsmnt_mark->mask; + marks_ignored_mask |= vfsmnt_mark->ignored_mask; } if (d_is_dir(path->dentry) && -- 2.7.4

6 years, 9 months

3
2
0 0

[PATCH] xhci: Fix Kernel oops in xhci dbgtty

by Mathias Nyman

From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com> tty_unregister_driver may be called more than 1 time in some hotplug cases,it will cause the kernel oops. This patch checked dbc_tty_driver to make sure it is unregistered only 1 time. [ 175.741404] BUG: unable to handle kernel NULL pointer dereference at 0000000000000034 [ 175.742309] IP: tty_unregister_driver+0x9/0x70 [ 175.743148] PGD 0 P4D 0 [ 175.743981] Oops: 0000 [#1] SMP PTI [ 175.753904] RIP: 0010:tty_unregister_driver+0x9/0x70 [ 175.754817] RSP: 0018:ffffa8ff831d3bb0 EFLAGS: 00010246 [ 175.755753] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 175.756685] RDX: ffff92089c616000 RSI: ffffe64fe1b26080 RDI: 0000000000000000 [ 175.757608] RBP: ffff92086c988230 R08: 000000006c982701 R09: 00000001801e0016 [ 175.758533] R10: ffffa8ff831d3b48 R11: ffff92086c982100 R12: ffff92086c98827c [ 175.759462] R13: ffff92086c988398 R14: 0000000000000060 R15: ffff92089c5e9b40 [ 175.760401] FS: 0000000000000000(0000) GS:ffff9208a0100000(0000) knlGS:0000000000000000 [ 175.761334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 175.762270] CR2: 0000000000000034 CR3: 000000011800a003 CR4: 00000000003606e0 [ 175.763225] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 175.764164] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 175.765091] Call Trace: [ 175.766014] xhci_dbc_tty_unregister_driver+0x11/0x30 [ 175.766960] xhci_dbc_exit+0x2a/0x40 [ 175.767889] xhci_stop+0x57/0x1c0 [ 175.768824] usb_remove_hcd+0x100/0x250 [ 175.769708] usb_hcd_pci_remove+0x68/0x130 [ 175.770574] pci_device_remove+0x3b/0xc0 [ 175.771435] device_release_driver_internal+0x157/0x230 [ 175.772343] pci_stop_bus_device+0x74/0xa0 [ 175.773205] pci_stop_bus_device+0x2b/0xa0 [ 175.774061] pci_stop_bus_device+0x2b/0xa0 [ 175.774907] pci_stop_bus_device+0x2b/0xa0 [ 175.775741] pci_stop_bus_device+0x2b/0xa0 [ 175.776618] pci_stop_bus_device+0x2b/0xa0 [ 175.777452] pci_stop_bus_device+0x2b/0xa0 [ 175.778273] pci_stop_bus_device+0x2b/0xa0 [ 175.779092] pci_stop_bus_device+0x2b/0xa0 [ 175.779908] pci_stop_bus_device+0x2b/0xa0 [ 175.780750] pci_stop_bus_device+0x2b/0xa0 [ 175.781543] pci_stop_and_remove_bus_device+0xe/0x20 [ 175.782338] pciehp_unconfigure_device+0xb8/0x160 [ 175.783128] pciehp_disable_slot+0x4f/0xd0 [ 175.783920] pciehp_power_thread+0x82/0xa0 [ 175.784766] process_one_work+0x147/0x3c0 [ 175.785564] worker_thread+0x4a/0x440 [ 175.786376] kthread+0xf8/0x130 [ 175.787174] ? rescuer_thread+0x360/0x360 [ 175.787964] ? kthread_associate_blkcg+0x90/0x90 [ 175.788798] ret_from_fork+0x35/0x40 Cc: <stable(a)vger.kernel.org> # 4.16 Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com> Tested-by: Christian Kellner <christian(a)kellner.me> Reviewed-by: Christian Kellner <christian(a)kellner.me> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-dbgtty.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index 48779c4..eb494ec5 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -320,9 +320,11 @@ int xhci_dbc_tty_register_driver(struct xhci_hcd *xhci) void xhci_dbc_tty_unregister_driver(void) { - tty_unregister_driver(dbc_tty_driver); - put_tty_driver(dbc_tty_driver); - dbc_tty_driver = NULL; + if (dbc_tty_driver) { + tty_unregister_driver(dbc_tty_driver); + put_tty_driver(dbc_tty_driver); + dbc_tty_driver = NULL; + } } static void dbc_rx_push(unsigned long _port) -- 2.7.4

6 years, 9 months

1
0
0 0

[PATCH] scsi_transport_srp: Fix shost to rport translation

by Bart Van Assche

Since an SRP remote port is attached as a child to shost->shost_gendev and as the only child, the translation from the shost pointer into an rport pointer must happen by looking up the shost child that is an rport. This patch fixes the following KASAN complaint: BUG: KASAN: slab-out-of-bounds in srp_timed_out+0x57/0x110 [scsi_transport_srp] Read of size 4 at addr ffff880035d3fcc0 by task kworker/1:0H/19 CPU: 1 PID: 19 Comm: kworker/1:0H Not tainted 4.16.0-rc3-dbg+ #1 Workqueue: kblockd blk_mq_timeout_work Call Trace: dump_stack+0x85/0xc7 print_address_description+0x65/0x270 kasan_report+0x231/0x350 srp_timed_out+0x57/0x110 [scsi_transport_srp] scsi_times_out+0xc7/0x3f0 [scsi_mod] blk_mq_terminate_expired+0xc2/0x140 bt_iter+0xbc/0xd0 blk_mq_queue_tag_busy_iter+0x1c7/0x350 blk_mq_timeout_work+0x325/0x3f0 process_one_work+0x441/0xa50 worker_thread+0x76/0x6c0 kthread+0x1b2/0x1d0 ret_from_fork+0x24/0x30 Fixes: e68ca75200fe ("scsi_transport_srp: Reduce failover time") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: Doug Ledford <dledford(a)redhat.com> Cc: Laurence Oberman <loberman(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/scsi/scsi_transport_srp.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_transport_srp.c b/drivers/scsi/scsi_transport_srp.c index 36f6190931bc..0d0515615847 100644 --- a/drivers/scsi/scsi_transport_srp.c +++ b/drivers/scsi/scsi_transport_srp.c @@ -51,6 +51,8 @@ struct srp_internal { struct transport_container rport_attr_cont; }; +static int scsi_is_srp_rport(const struct device *dev); + #define to_srp_internal(tmpl) container_of(tmpl, struct srp_internal, t) #define dev_to_rport(d) container_of(d, struct srp_rport, dev) @@ -60,9 +62,24 @@ static inline struct Scsi_Host *rport_to_shost(struct srp_rport *r) return dev_to_shost(r->dev.parent); } +static int find_child_rport(struct device *dev, void *data) +{ + struct device **child = data; + + if (scsi_is_srp_rport(dev)) { + WARN_ON_ONCE(*child); + *child = dev; + } + return 0; +} + static inline struct srp_rport *shost_to_rport(struct Scsi_Host *shost) { - return transport_class_to_srp_rport(&shost->shost_gendev); + struct device *child = NULL; + + WARN_ON_ONCE(device_for_each_child(&shost->shost_gendev, &child, + find_child_rport) < 0); + return child ? dev_to_rport(child) : NULL; } /** -- 2.16.2

6 years, 9 months

3
2
0 0

v4.13+ stable backport request

by Jani Nikula

Stable team, please backport commit a306343bcd7d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") to v4.13+ Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link training failure") BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

6 years, 9 months

3
6
0 0

[PATCH] mm, slab: reschedule cache_reap() on the same CPU

by Vlastimil Babka

cache_reap() is initially scheduled in start_cpu_timer() via schedule_delayed_work_on(). But then the next iterations are scheduled via schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND. Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs") there is no guarantee the future iterations will run on the originally intended cpu, although it's still preferred. I was able to demonstrate this with /sys/module/workqueue/parameters/debug_force_rr_cpu. IIUC, it may also happen due to migrating timers in nohz context. As a result, some cpu's would be calling cache_reap() more frequently and others never. This patch uses schedule_delayed_work_on() with the current cpu when scheduling the next iteration. Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Fixes: ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs") CC: <stable(a)vger.kernel.org> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: Christoph Lameter <cl(a)linux.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Lai Jiangshan <jiangshanlai(a)gmail.com> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Stephen Boyd <sboyd(a)kernel.org> --- mm/slab.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/slab.c b/mm/slab.c index 9095c3945425..a76006aae857 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -4074,7 +4074,8 @@ static void cache_reap(struct work_struct *w) next_reap_node(); out: /* Set up the next iteration */ - schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC)); + schedule_delayed_work_on(smp_processor_id(), work, + round_jiffies_relative(REAPTIMEOUT_AC)); } void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo) -- 2.16.3

6 years, 9 months

4
4
0 0

[PATCH AUTOSEL for 4.9 001/293] ALSA: timer: Wrap with spinlock for queue access

by Sasha Levin

From: Takashi Iwai <tiwai(a)suse.de> [ Upstream commit d7f910bfedd863d13ea320030fe98e42d0938ed5 ] For accessing the snd_timer_user queue indices, we take tu->qlock. But it's forgotten in a couple of places. The one in snd_timer_user_params() should be safe without the spinlock as the timer is already stopped. But it's better for consistency. The one in poll is just a read-out, so it's not inevitably needed, but it'd be good to make the result consistent, too. Tested-by: Alexander Potapenko <glider(a)google.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- sound/core/timer.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index e5ddc475dca4..bbde1bcdd985 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -1773,6 +1773,7 @@ static int snd_timer_user_params(struct file *file, } } } + spin_lock_irq(&tu->qlock); tu->qhead = tu->qtail = tu->qused = 0; if (tu->timeri->flags & SNDRV_TIMER_IFLG_EARLY_EVENT) { if (tu->tread) { @@ -1793,6 +1794,7 @@ static int snd_timer_user_params(struct file *file, } tu->filter = params.filter; tu->ticks = params.ticks; + spin_unlock_irq(&tu->qlock); err = 0; _end: if (copy_to_user(_params, &params, sizeof(params))) @@ -2034,10 +2036,12 @@ static unsigned int snd_timer_user_poll(struct file *file, poll_table * wait) poll_wait(file, &tu->qchange_sleep, wait); mask = 0; + spin_lock_irq(&tu->qlock); if (tu->qused) mask |= POLLIN | POLLRDNORM; if (tu->disconnected) mask |= POLLERR; + spin_unlock_irq(&tu->qlock); return mask; } -- 2.15.1

6 years, 9 months

4
295
0 0

[PATCH] drm/i915/dp: Fix intel_edp_compare_alt_mode.

by Maarten Lankhorst

On fi-cnl-y3 we have 2 modes that differ only by crtc_clock. This means that if we request the normal mode, we automatically get the downclocked mode. This can be seen during boot: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:101:eDP-1] probed modes : [drm:drm_mode_debug_printmodeline] Modeline 102:"3840x2160" 60 533250 3840 3888 3920 4000 2160 2163 2168 2222 0x48 0xa [drm:drm_mode_debug_printmodeline] Modeline 103:"3840x2160" 48 426600 3840 3888 3920 4000 2160 2163 2168 2222 0x40 0xa ... [drm:intel_dump_pipe_config [i915]] [CRTC:51:pipe A][modeset] [drm:intel_dump_pipe_config [i915]] output_types: EDP (0x100) [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0 [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 4; gmch_m: 4970250, gmch_n: 8388608, link_m: 828375, link_n: 1048576, tu: 64 [drm:intel_dump_pipe_config [i915]] dp m2_n2: lanes: 4; gmch_m: 4970250, gmch_n: 8388608, link_m: 828375, link_n: 1048576, tu: 64 [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0 [drm:intel_dump_pipe_config [i915]] requested mode: [drm:drm_mode_debug_printmodeline] Modeline 0:"3840x2160" 60 533250 3840 3888 3920 4000 2160 2163 2168 2222 0x48 0xa [drm:intel_dump_pipe_config [i915]] adjusted mode: [drm:drm_mode_debug_printmodeline] Modeline 0:"3840x2160" 48 426600 3840 3888 3920 4000 2160 2163 2168 2222 0x40 0xa Testcase: kms_panel_fitting.atomic-fastset Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP if available.") Cc: David Weinehall <david.weinehall(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Paulo Zanoni <paulo.r.zanoni(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Jim Bride <jim.bride(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v4.14+ --- drivers/gpu/drm/i915/intel_dp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 9a4a51e79fa1..0bd3cc1c82b4 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1684,7 +1684,8 @@ static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1, m1->vdisplay == m2->vdisplay && m1->vsync_start == m2->vsync_start && m1->vsync_end == m2->vsync_end && - m1->vtotal == m2->vtotal); + m1->vtotal == m2->vtotal && + m1->clock == m2->clock); return bres; } -- 2.16.2

6 years, 9 months

4
9
0 0

[alternative-merged] resource-fix-integer-overflow-at-reallocation.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: resource: fix integer overflow at reallocation has been removed from the -mm tree. Its filename was resource-fix-integer-overflow-at-reallocation.patch This patch was dropped because an alternative patch was merged ------------------------------------------------------ From: Takashi Iwai <tiwai(a)suse.de> Subject: resource: fix integer overflow at reallocation We've got a bug report indicating a kernel panic at booting on an x86-32 system, and it turned out to be the invalid resource assigned after PCI resource reallocation. __find_resource() first aligns the resource start address and resets the end address with start+size-1 accordingly, then checks whether it's contained. Here the end address may overflow the integer, although resource_contains() still returns true because the function validates only start and end address. So this ends up with returning an invalid resource (start > end). There was already an attempt to cover such a problem in the commit 47ea91b4052d ("Resource: fix wrong resource window calculation"), but this case is an overseen one. This patch adds the validity check in resource_contains() to see whether the given resource has a valid range for avoiding the integer overflow problem. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739 Link: http://lkml.kernel.org/r/20180408072026.27365-1-tiwai@suse.de Fixes: 23c570a67448 ("resource: ability to resize an allocated resource") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Reported-by: Michael Henders <hendersm(a)shaw.ca> Tested-by: Michael Henders <hendersm(a)shaw.ca> Reviewed-by: Ram Pai <linuxram(a)us.ibm.com> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/ioport.h | 3 +++ 1 file changed, 3 insertions(+) diff -puN include/linux/ioport.h~resource-fix-integer-overflow-at-reallocation include/linux/ioport.h --- a/include/linux/ioport.h~resource-fix-integer-overflow-at-reallocation +++ a/include/linux/ioport.h @@ -212,6 +212,9 @@ static inline bool resource_contains(str return false; if (r1->flags & IORESOURCE_UNSET || r2->flags & IORESOURCE_UNSET) return false; + /* sanity check whether it's a valid resource range */ + if (r2->end < r2->start) + return false; return r1->start <= r2->start && r1->end >= r2->end; } _ Patches currently in -mm which might be from tiwai(a)suse.de are resource-fix-integer-overflow-at-reallocation-v1.patch

6 years, 9 months

1
0
0 0

+ rapidio-fix-rio_dma_transfer-error-handling.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: rapidio: fix rio_dma_transfer error handling has been added to the -mm tree. Its filename is rapidio-fix-rio_dma_transfer-error-handling.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/rapidio-fix-rio_dma_transfer-error… and later at http://ozlabs.org/~akpm/mmotm/broken-out/rapidio-fix-rio_dma_transfer-error… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Ioan Nicu <ioan.nicu.ext(a)nokia.com> Subject: rapidio: fix rio_dma_transfer error handling Some of the mport_dma_req structure members were initialized late inside the do_dma_request() function, just before submitting the request to the dma engine. But we have some error branches before that. In case of such an error, the code would return on the error path and trigger the calling of dma_req_free() with a req structure which is not completely initialized. This causes a NULL pointer dereference in dma_req_free(). This patch fixes these error branches by making sure that all necessary mport_dma_req structure members are initialized in rio_dma_transfer() immediately after the request structure gets allocated. Link: http://lkml.kernel.org/r/20180412150605.GA31409@nokia.com Signed-off-by: Ioan Nicu <ioan.nicu.ext(a)nokia.com> Tested-by: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> Acked-by: Alexandre Bounine <alex.bou9(a)gmail.com> Cc: Barry Wood <barry.wood(a)idt.com> Cc: Matt Porter <mporter(a)kernel.crashing.org> Cc: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Cc: Logan Gunthorpe <logang(a)deltatee.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Frank Kunz <frank.kunz(a)nokia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/rapidio/devices/rio_mport_cdev.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff -puN drivers/rapidio/devices/rio_mport_cdev.c~rapidio-fix-rio_dma_transfer-error-handling drivers/rapidio/devices/rio_mport_cdev.c --- a/drivers/rapidio/devices/rio_mport_cdev.c~rapidio-fix-rio_dma_transfer-error-handling +++ a/drivers/rapidio/devices/rio_mport_cdev.c @@ -740,10 +740,7 @@ static int do_dma_request(struct mport_d tx->callback = dma_xfer_callback; tx->callback_param = req; - req->dmach = chan; - req->sync = sync; req->status = DMA_IN_PROGRESS; - init_completion(&req->req_comp); kref_get(&req->refcount); cookie = dmaengine_submit(tx); @@ -831,13 +828,20 @@ rio_dma_transfer(struct file *filp, u32 if (!req) return -ENOMEM; - kref_init(&req->refcount); - ret = get_dma_channel(priv); if (ret) { kfree(req); return ret; } + chan = priv->dmach; + + kref_init(&req->refcount); + init_completion(&req->req_comp); + req->dir = dir; + req->filp = filp; + req->priv = priv; + req->dmach = chan; + req->sync = sync; /* * If parameter loc_addr != NULL, we are transferring data from/to @@ -925,11 +929,6 @@ rio_dma_transfer(struct file *filp, u32 xfer->offset, xfer->length); } - req->dir = dir; - req->filp = filp; - req->priv = priv; - chan = priv->dmach; - nents = dma_map_sg(chan->device->dev, req->sgt.sgl, req->sgt.nents, dir); if (nents == 0) { _ Patches currently in -mm which might be from ioan.nicu.ext(a)nokia.com are rapidio-fix-rio_dma_transfer-error-handling.patch

6 years, 9 months

1
0
0 0

Targeted Global B2B Companies Emails List

by joann.kaur＠dedicatedaccounts.com

Hi, Hope all is well! We are a database organization. We provide business executives' contact information. Below, I've included a few examples: Industry-Specific Lists: Agriculture, Business Services, Chambers of Commerce, Cities, Towns & Municipalities, Construction, Consumer Services, Cultural, Education, Energy, Utilities & Waste Treatment, Finance, Government, Healthcare, Hospitality, Insurance, Law Firms & Legal Services, Manufacturing, Media & Internet, Metals & Mining, Organizations, Real Estate, Retail, Software, Telecommunications, Transportation, and more! Technology-Specific Lists: SAP users, PeopleSoft users, SIEBEL customers, Oracle Application customers, Microsoft Dynamic users, Sales force users, Microsoft Exchange users, QuickBooks, Lawson users, Act users, JD Edward users, ASP users, Microsoft GP Applications users, Net Suite users, IBM DBMS Application users, McAfee users, MS Dynamics GP (Great Plains), and many more. Title-Specific Lists: C-level executives: CEO, CFO, CIO, CTO, CMO, CISO, CSO, COO Key decision-makers: All C-level, VP-level, and Director-level executives HR Executives: VP of HR, HR Director & HR Manager, etc. Marketing Executives: CMO, VP of Marketing, Director of Marketing, Marketing Managers IT Executives: CIO, CTO, CISO, IT-VP, IT-Director, IT Manager, MIS Manager, etc. Please keep me informed for any additional details. I look forward to hearing from you. Regards, Joann Kaur Marketing Executive

6 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2018