* ->poll() instances shouldn't be indefinitely blocking
@ 2015-11-27 5:00 Al Viro
2015-11-27 15:18 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 12+ messages in thread
From: Al Viro @ 2015-11-27 5:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linus Torvalds, linux-kernel, linux-fsdevel
Take a look at this:
static unsigned int gsc_m2m_poll(struct file *file,
struct poll_table_struct *wait)
{
struct gsc_ctx *ctx = fh_to_ctx(file->private_data);
struct gsc_dev *gsc = ctx->gsc_dev;
int ret;
if (mutex_lock_interruptible(&gsc->lock))
return -ERESTARTSYS;
ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
mutex_unlock(&gsc->lock);
return ret;
}
a) ->poll() should not return -E...; callers expect just a bitmap of
POLL... values.
b) sure, it's nice that if this thing hangs, we'll be able to kill it.
However, if one's ->poll() can hang indefinitely, it means bad things
for poll(2), select(2), etc. semantics. What the hell had been intended
there?
c) a bunch of v4l2_m2m_poll() callers are also taking some kind of
mutex; AFAICS, all of those appear bogus (the rest of them do not
play wiht ERESTARTSYS, just plain mutex_lock() for those).
What's going on there?
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: ->poll() instances shouldn't be indefinitely blocking 2015-11-27 5:00 ->poll() instances shouldn't be indefinitely blocking Al Viro @ 2015-11-27 15:18 ` Mauro Carvalho Chehab 2015-11-27 17:49 ` Linus Torvalds 0 siblings, 1 reply; 12+ messages in thread From: Mauro Carvalho Chehab @ 2015-11-27 15:18 UTC (permalink / raw) To: Al Viro Cc: Linus Torvalds, linux-kernel, linux-fsdevel, linux-media, Kukjin Kim, Krzysztof Kozlowski, Hans Verkuil Em Fri, 27 Nov 2015 05:00:26 +0000 Al Viro <viro@ZenIV.linux.org.uk> escreveu: > Take a look at this: > static unsigned int gsc_m2m_poll(struct file *file, > struct poll_table_struct *wait) > { > struct gsc_ctx *ctx = fh_to_ctx(file->private_data); > struct gsc_dev *gsc = ctx->gsc_dev; > int ret; > > if (mutex_lock_interruptible(&gsc->lock)) > return -ERESTARTSYS; > > ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait); > mutex_unlock(&gsc->lock); > > return ret; > } > > a) ->poll() should not return -E...; callers expect just a bitmap of > POLL... values. Yeah. We fixed issues like that on other drivers along the time. I guess this is a some bad code that people just cut-and-paste from legacy drivers without looking into it. The same kind of crap were found (and fixed) on other drivers, like the fix on this changeset: 45053edc05 ('[media] saa7164: fix poll bugs'). > b) sure, it's nice that if this thing hangs, we'll be able to kill it. > However, if one's ->poll() can hang indefinitely, it means bad things > for poll(2), select(2), etc. semantics. What the hell had been intended > there? I guess there was no special intent. It is just a bad driver code that was replicated from other drivers. > c) a bunch of v4l2_m2m_poll() callers are also taking some kind of > mutex; AFAICS, all of those appear bogus (the rest of them do not > play wiht ERESTARTSYS, just plain mutex_lock() for those). > > What's going on there? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ->poll() instances shouldn't be indefinitely blocking 2015-11-27 15:18 ` Mauro Carvalho Chehab @ 2015-11-27 17:49 ` Linus Torvalds 2015-11-30 3:04 ` Al Viro 0 siblings, 1 reply; 12+ messages in thread From: Linus Torvalds @ 2015-11-27 17:49 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Al Viro, Linux Kernel Mailing List, linux-fsdevel, Linux Media Mailing List, Kukjin Kim, Krzysztof Kozlowski, Hans Verkuil On Fri, Nov 27, 2015 at 7:18 AM, Mauro Carvalho Chehab <mchehab@osg.samsung.com> wrote: > Al Viro <viro@ZenIV.linux.org.uk> escreveu: > >> Take a look at this: >> static unsigned int gsc_m2m_poll(struct file *file, >> struct poll_table_struct *wait) >> { >> struct gsc_ctx *ctx = fh_to_ctx(file->private_data); >> struct gsc_dev *gsc = ctx->gsc_dev; >> int ret; >> >> if (mutex_lock_interruptible(&gsc->lock)) >> return -ERESTARTSYS; >> >> ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait); >> mutex_unlock(&gsc->lock); >> >> return ret; >> } >> >> a) ->poll() should not return -E...; callers expect just a bitmap of >> POLL... values. > > Yeah. We fixed issues like that on other drivers along the time. I guess > this is a some bad code that people just cut-and-paste from legacy drivers > without looking into it. Actually, while returning -ERESTARTSYS is bogus, returning _zero_ would not be. The top-level poll() code will happily notice the signal, and return -EINTR like poll should (unless something else is pending, in which case it will return zero and the bits set for that something else). So having a driver with a ->poll() function that does that kind of conditional locking is not wrong per se. It's just he return value that is crap. I also do wonder if we might not make the generic code a bit more robust wrt things like this. The bitmask we use is only about the low bits, so we *could* certainly allow the driver poll() functions to return errors - possibly just ignoring them. Or perhaps have a WARN_ON_OCNE() to find them. Al, what do you think? The whole "generic code should be robust wrt drivers making silly mistakes" just sounds like a good idea. Finding these things through code inspection is all well and good, but having a nice warning report from users might be even better. Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ->poll() instances shouldn't be indefinitely blocking 2015-11-27 17:49 ` Linus Torvalds @ 2015-11-30 3:04 ` Al Viro 2015-12-04 6:38 ` more POLL... fun Al Viro 0 siblings, 1 reply; 12+ messages in thread From: Al Viro @ 2015-11-30 3:04 UTC (permalink / raw) To: Linus Torvalds Cc: Mauro Carvalho Chehab, Linux Kernel Mailing List, linux-fsdevel, Linux Media Mailing List, Kukjin Kim, Krzysztof Kozlowski, Hans Verkuil On Fri, Nov 27, 2015 at 09:49:11AM -0800, Linus Torvalds wrote: > Al, what do you think? The whole "generic code should be robust wrt > drivers making silly mistakes" just sounds like a good idea. Finding > these things through code inspection is all well and good, but having > a nice warning report from users might be even better. FWIW, sparse catches them just fine here. I don't mind using the MSB as a canary, but AFAICS that code tends to be rarely hit, so this kind of runtime warning isn't going to be all that useful. The current list is: drivers/media/platform/exynos-gsc/gsc-m2m.c:707:24: expected restricted __poll_t drivers/media/platform/exynos-gsc/gsc-m2m.c:707:24: got int drivers/media/platform/exynos-gsc/gsc-m2m.c:707:24: warning: incorrect type in return expression (different base types) --- this one drivers/media/platform/s3c-camif/camif-capture.c:615:21: expected restricted __poll_t [usertype] ret drivers/media/platform/s3c-camif/camif-capture.c:615:21: got int drivers/media/platform/s3c-camif/camif-capture.c:615:21: warning: incorrect type in assignment (different base types) mutex_lock(&camif->lock); if (vp->owner && vp->owner != file->private_data) ret = -EBUSY; else ret = vb2_poll(&vp->vb_queue, file, wait); --- not nice drivers/media/radio/radio-wl1273.c:1092:24: expected restricted __poll_t drivers/media/radio/radio-wl1273.c:1092:24: got int drivers/media/radio/radio-wl1273.c:1092:24: warning: incorrect type in return expression (different base types) struct wl1273_device *radio = video_get_drvdata(video_devdata(file)); struct wl1273_core *core = radio->core; if (radio->owner && radio->owner != file) return -EBUSY; radio->owner = file; --- obviously racy, not to mention anything else (that's the very beginning of ->poll() instance) drivers/staging/rdma/hfi1/diag.c:798:24: expected restricted __poll_t drivers/staging/rdma/hfi1/diag.c:798:24: got int drivers/staging/rdma/hfi1/diag.c:798:24: warning: incorrect type in return expression (different base types) dd = hfi1_dd_from_sc_inode(fp->f_inode); if (dd == NULL) return -ENODEV; --- hadn't looked yet drivers/misc/mei/main.c:668:24: expected int drivers/misc/mei/main.c:668:24: got restricted __poll_t [usertype] <noident> drivers/misc/mei/main.c:668:24: warning: incorrect type in return expression (different base types) --- this one is other way round - it's ->fasync() returning POLLERR; the author told of that one, says it's a cut'n'paste bug. Hopefully will get fixed... drivers/tty/n_r3964.c:1241:24: expected restricted __poll_t [assigned] [usertype] result drivers/tty/n_r3964.c:1241:24: got int drivers/tty/n_r3964.c:1241:24: warning: incorrect type in assignment (different base types) pClient = findClient(pInfo, task_pid(current)); if (pClient) { ... } else { result = -EINVAL; --- maybe it's just me, but this looks utterly bogus. task_pid(current)? Really? drivers/uio/uio.c:497:24: expected restricted __poll_t drivers/uio/uio.c:497:24: got int drivers/uio/uio.c:497:24: warning: incorrect type in return expression (different base types) if (!idev->info->irq) return -EIO; --- bogosity aside, I really don't like the look of the lifetime rules for the thing idev->info points to in that one. Looks like unregistration *can* happen while the sucker's open, and it won't wait for anything to run down. kernel/time/posix-clock.c:75:24: expected restricted __poll_t kernel/time/posix-clock.c:75:24: got int --- that one does deal with unregistration, but (a) returns a bogus value and (b) does down_read(&clk->rwsem), which might be not nice in ->poll() instance. kernel/trace/ring_buffer.c:640:32: expected restricted __poll_t kernel/trace/ring_buffer.c:640:32: got int kernel/trace/ring_buffer.c:640:32: warning: incorrect type in return expression (different base types) --- might be racy, in any case the return value is bogus sound/core/compress_offload.c:381:24: expected restricted __poll_t sound/core/compress_offload.c:381:24: got int sound/core/compress_offload.c:381:24: warning: incorrect type in return expression (different base types) sound/core/compress_offload.c:384:24: expected restricted __poll_t sound/core/compress_offload.c:384:24: got int sound/core/compress_offload.c:384:24: warning: incorrect type in return expression (different base types) --- a couple of "what do we return after struct file being stomped upon, because it can't happen in any other way" sound/core/compress_offload.c:388:24: expected restricted __poll_t [usertype] retval sound/core/compress_offload.c:388:24: got int sound/core/compress_offload.c:388:24: warning: incorrect type in assignment (different base types) sound/core/pcm_native.c:3152:24: expected restricted __poll_t sound/core/pcm_native.c:3152:24: got int sound/core/pcm_native.c:3152:24: warning: incorrect type in return expression (different base types) sound/core/pcm_native.c:3191:24: expected restricted __poll_t sound/core/pcm_native.c:3191:24: got int sound/core/pcm_native.c:3191:24: warning: incorrect type in return expression (different base types) --- not sure, hadn't looked in detail. sound/core/seq/oss/seq_oss.c:203:24: expected restricted __poll_t sound/core/seq/oss/seq_oss.c:203:24: got int sound/core/seq/oss/seq_oss.c:203:24: warning: incorrect type in return expression (different base types) --- impossible to hit without struct file being corrupted sound/core/seq/seq_clientmgr.c:1102:24: expected restricted __poll_t sound/core/seq/seq_clientmgr.c:1102:24: got int sound/core/seq/seq_clientmgr.c:1102:24: warning: incorrect type in return expression (different base types) --- ditto drivers/gpu/vga/vgaarb.c:1169:24: warning: incorrect type in return expression (different base types) drivers/gpu/vga/vgaarb.c:1169:24: expected restricted __poll_t drivers/gpu/vga/vgaarb.c:1169:24: got int --- ditto That's on amd64/allmodconfig build with the annotations I'd done for ->poll(). They also have caught a couple of dubious places in net/9p, still looking in there. FWIW, the typical impact of annotations on a driver is something like @@ -2155,11 +2155,11 @@ pmu_write(struct file *file, const char __user *buf, return 0; } -static unsigned int +static __poll_t pmu_fpoll(struct file *filp, poll_table *wait) { struct pmu_private *pp = filp->private_data; - unsigned int mask = 0; + __poll_t mask = 0; unsigned long flags; if (pp == 0) IOW, not really intrusive. make C=2 CF="-D__CHECK_ENDIAN -D__CHECK_POLL__" right now, might as well make poll annotations trigger on __CHECK_ENDIAN__ alone - there's not much noise left. Again, I have no problem with adding "if the MSB is set, it's probably a broken driver returning -E... instead of the valid bitmap, let's warn about it", but IMO it's better dealt with by sparse at build time; bogus values are not returned on common paths, so the runtime test coverage won't be good. See vfs.git#work.poll-annotations for the current state of that queue. The last commit needs to be split and folded back into the relevant commits before - the queue was originally done back in March and last week I'd ported it to current mainline, the last commit being the annotations in the code that had been added since then. The current summary follows: Shortlog: Al Viro (20): switch poll.h to generic-y where possible annotate POLL... constants and ->poll() return value annotate poll_table_struct->_key and poll_table_entry->key annotate wake_..._poll() last argument fs: annotate ->poll() instances annotate proto_ops ->poll() annotate proto_ops ->poll() instances net: annotate file_operations ->poll() instances kernel: annotate ->poll() instances annotate posix clock annotate security/ annotate mm/ annotate ipc/ annotate drivers/media and its users annotate sound/ annotate tty annotate assorted drivers VFS annotations annotations around wakeup callbacks missing ->poll() annotations [splitme] Diffstat: arch/alpha/include/asm/Kbuild | 1 + arch/alpha/include/uapi/asm/poll.h | 1 - arch/blackfin/include/uapi/asm/poll.h | 4 +-- arch/cris/arch-v10/drivers/gpio.c | 6 ++-- arch/cris/arch-v10/drivers/sync_serial.c | 8 ++--- arch/cris/arch-v32/drivers/sync_serial.c | 8 ++--- arch/frv/include/uapi/asm/poll.h | 2 +- arch/ia64/include/asm/Kbuild | 1 + arch/ia64/include/uapi/asm/poll.h | 1 - arch/ia64/kernel/perfmon.c | 4 +-- arch/m32r/include/asm/Kbuild | 1 + arch/m32r/include/uapi/asm/poll.h | 1 - arch/m68k/include/uapi/asm/poll.h | 2 +- arch/microblaze/include/asm/Kbuild | 1 + arch/microblaze/include/uapi/asm/poll.h | 1 - arch/mips/include/uapi/asm/poll.h | 2 +- arch/mips/kernel/rtlx.c | 4 +-- arch/mn10300/include/asm/Kbuild | 1 + arch/mn10300/include/uapi/asm/poll.h | 1 - arch/powerpc/include/asm/Kbuild | 1 + arch/powerpc/include/uapi/asm/poll.h | 1 - arch/powerpc/kernel/rtasd.c | 2 +- arch/powerpc/platforms/cell/spufs/file.c | 16 +++++----- arch/powerpc/platforms/powernv/opal-prd.c | 2 +- arch/s390/include/asm/Kbuild | 1 + arch/s390/include/uapi/asm/poll.h | 1 - arch/score/include/asm/Kbuild | 1 + arch/score/include/uapi/asm/poll.h | 6 ---- arch/sparc/include/uapi/asm/poll.h | 8 ++--- arch/um/drivers/hostaudio_kern.c | 4 +-- arch/um/include/asm/Kbuild | 1 + arch/x86/include/asm/Kbuild | 1 + arch/x86/include/uapi/asm/poll.h | 1 - arch/x86/kernel/apm_32.c | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 2 +- arch/xtensa/include/uapi/asm/poll.h | 4 +-- block/bsg.c | 4 +-- crypto/algif_aead.c | 4 +-- crypto/algif_skcipher.c | 6 ++-- drivers/android/binder.c | 2 +- drivers/bluetooth/hci_ldisc.c | 2 +- drivers/bluetooth/hci_vhci.c | 2 +- drivers/char/apm-emulation.c | 2 +- drivers/char/dtlk.c | 6 ++-- drivers/char/genrtc.c | 2 +- drivers/char/hpet.c | 2 +- drivers/char/ipmi/ipmi_devintf.c | 4 +-- drivers/char/ipmi/ipmi_watchdog.c | 4 +-- drivers/char/pcmcia/cm4040_cs.c | 4 +-- drivers/char/ppdev.c | 4 +-- drivers/char/random.c | 4 +-- drivers/char/rtc.c | 4 +-- drivers/char/snsc.c | 4 +-- drivers/char/sonypi.c | 2 +- drivers/char/virtio_console.c | 4 +-- drivers/char/xillybus/xillybus_core.c | 4 +-- drivers/dma-buf/dma-buf.c | 6 ++-- drivers/firewire/core-cdev.c | 4 +-- drivers/firewire/nosy.c | 4 +-- drivers/gpu/drm/drm_fops.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 +- drivers/gpu/vga/vgaarb.c | 2 +- drivers/hid/hid-debug.c | 2 +- drivers/hid/hid-roccat.c | 2 +- drivers/hid/hid-sensor-custom.c | 4 +-- drivers/hid/hidraw.c | 2 +- drivers/hid/uhid.c | 2 +- drivers/hid/usbhid/hiddev.c | 2 +- drivers/hsi/clients/cmt_speech.c | 4 +-- drivers/hv/hv_utils_transport.c | 2 +- drivers/iio/iio_core.h | 2 +- drivers/iio/industrialio-buffer.c | 2 +- drivers/iio/industrialio-event.c | 4 +-- drivers/infiniband/core/ucm.c | 4 +-- drivers/infiniband/core/ucma.c | 4 +-- drivers/infiniband/core/user_mad.c | 4 +-- drivers/infiniband/core/uverbs_main.c | 4 +-- drivers/infiniband/hw/qib/qib_file_ops.c | 14 ++++----- drivers/input/evdev.c | 4 +-- drivers/input/input.c | 2 +- drivers/input/joydev.c | 2 +- drivers/input/misc/hp_sdc_rtc.c | 4 +-- drivers/input/misc/uinput.c | 2 +- drivers/input/mousedev.c | 4 +-- drivers/input/serio/serio_raw.c | 4 +-- drivers/input/serio/userio.c | 2 +- drivers/isdn/capi/capi.c | 4 +-- drivers/isdn/divert/divert_procfs.c | 4 +-- drivers/isdn/hardware/eicon/divamnt.c | 4 +-- drivers/isdn/hardware/eicon/divasi.c | 4 +-- drivers/isdn/hardware/eicon/divasmain.c | 2 +- drivers/isdn/hardware/eicon/divasproc.c | 2 +- drivers/isdn/hysdn/hysdn_proclog.c | 4 +-- drivers/isdn/i4l/isdn_common.c | 4 +-- drivers/isdn/i4l/isdn_ppp.c | 4 +-- drivers/isdn/i4l/isdn_ppp.h | 2 +- drivers/isdn/mISDN/timerdev.c | 4 +-- drivers/macintosh/smu.c | 4 +-- drivers/macintosh/via-pmu.c | 4 +-- drivers/md/md.c | 4 +-- drivers/media/common/saa7146/saa7146_fops.c | 8 ++--- drivers/media/common/siano/smsdvb-debugfs.c | 7 ++--- drivers/media/dvb-core/dmxdev.c | 8 ++--- drivers/media/dvb-core/dvb_ca_en50221.c | 4 +-- drivers/media/dvb-core/dvb_frontend.c | 2 +- drivers/media/firewire/firedtv-ci.c | 2 +- drivers/media/media-devnode.c | 2 +- drivers/media/pci/bt8xx/bttv-driver.c | 12 ++++---- drivers/media/pci/cx18/cx18-fileops.c | 8 ++--- drivers/media/pci/cx18/cx18-fileops.h | 2 +- drivers/media/pci/ddbridge/ddbridge-core.c | 4 +-- drivers/media/pci/ivtv/ivtv-fileops.c | 10 +++--- drivers/media/pci/ivtv/ivtv-fileops.h | 4 +-- drivers/media/pci/meye/meye.c | 4 +-- drivers/media/pci/saa7134/saa7134-video.c | 4 +-- drivers/media/pci/saa7164/saa7164-encoder.c | 6 ++-- drivers/media/pci/saa7164/saa7164-vbi.c | 4 +-- drivers/media/pci/ttpci/av7110_av.c | 8 ++--- drivers/media/pci/ttpci/av7110_ca.c | 4 +-- drivers/media/pci/zoran/zoran_driver.c | 4 +-- drivers/media/platform/davinci/vpfe_capture.c | 2 +- drivers/media/platform/exynos-gsc/gsc-m2m.c | 4 +-- drivers/media/platform/fsl-viu.c | 6 ++-- drivers/media/platform/m2m-deinterlace.c | 4 +-- drivers/media/platform/mx2_emmaprp.c | 4 +-- drivers/media/platform/omap/omap_vout.c | 2 +- drivers/media/platform/omap3isp/ispvideo.c | 4 +-- drivers/media/platform/s3c-camif/camif-capture.c | 4 +-- drivers/media/platform/s5p-mfc/s5p_mfc.c | 4 +-- drivers/media/platform/s5p-tv/mixer_video.c | 4 +-- drivers/media/platform/sh_veu.c | 2 +- drivers/media/platform/soc_camera/atmel-isi.c | 2 +- drivers/media/platform/soc_camera/mx2_camera.c | 2 +- drivers/media/platform/soc_camera/mx3_camera.c | 2 +- drivers/media/platform/soc_camera/omap1_camera.c | 2 +- drivers/media/platform/soc_camera/pxa_camera.c | 2 +- drivers/media/platform/soc_camera/rcar_vin.c | 2 +- .../platform/soc_camera/sh_mobile_ceu_camera.c | 2 +- drivers/media/platform/soc_camera/soc_camera.c | 4 +-- drivers/media/platform/timblogiw.c | 2 +- drivers/media/platform/via-camera.c | 2 +- drivers/media/platform/vivid/vivid-core.c | 2 +- drivers/media/platform/vivid/vivid-radio-rx.c | 2 +- drivers/media/platform/vivid/vivid-radio-rx.h | 2 +- drivers/media/platform/vivid/vivid-radio-tx.c | 2 +- drivers/media/platform/vivid/vivid-radio-tx.h | 2 +- drivers/media/radio/radio-cadet.c | 6 ++-- drivers/media/radio/radio-si476x.c | 6 ++-- drivers/media/radio/radio-wl1273.c | 2 +- drivers/media/radio/si470x/radio-si470x-common.c | 6 ++-- drivers/media/radio/wl128x/fmdrv_v4l2.c | 2 +- drivers/media/rc/lirc_dev.c | 4 +-- drivers/media/usb/cpia2/cpia2.h | 4 +-- drivers/media/usb/cpia2/cpia2_core.c | 4 +-- drivers/media/usb/cpia2/cpia2_v4l.c | 4 +-- drivers/media/usb/cx231xx/cx231xx-417.c | 6 ++-- drivers/media/usb/cx231xx/cx231xx-video.c | 6 ++-- drivers/media/usb/gspca/gspca.c | 6 ++-- drivers/media/usb/hdpvr/hdpvr-video.c | 6 ++-- drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 4 +-- drivers/media/usb/stkwebcam/stk-webcam.c | 4 +-- drivers/media/usb/tm6000/tm6000-video.c | 10 +++--- drivers/media/usb/uvc/uvc_queue.c | 4 +-- drivers/media/usb/uvc/uvc_v4l2.c | 2 +- drivers/media/usb/uvc/uvcvideo.h | 2 +- drivers/media/usb/zr364xx/zr364xx.c | 4 +-- drivers/media/v4l2-core/v4l2-ctrls.c | 2 +- drivers/media/v4l2-core/v4l2-dev.c | 4 +-- drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +++--- drivers/media/v4l2-core/v4l2-subdev.c | 2 +- drivers/media/v4l2-core/videobuf-core.c | 10 +++--- drivers/media/v4l2-core/videobuf2-v4l2.c | 10 +++--- drivers/misc/cxl/api.c | 2 +- drivers/misc/cxl/cxl.h | 2 +- drivers/misc/cxl/file.c | 4 +-- drivers/misc/hpilo.c | 2 +- drivers/misc/lis3lv02d/lis3lv02d.c | 2 +- drivers/misc/mei/amthif.c | 4 +-- drivers/misc/mei/main.c | 6 ++-- drivers/misc/mei/mei_dev.h | 2 +- drivers/misc/mic/host/mic_fops.c | 4 +-- drivers/misc/mic/host/mic_fops.h | 2 +- drivers/misc/mic/scif/scif_api.c | 7 +++-- drivers/misc/mic/scif/scif_epd.h | 2 +- drivers/misc/mic/scif/scif_fd.c | 2 +- drivers/misc/phantom.c | 4 +-- drivers/misc/vmw_vmci/vmci_host.c | 4 +-- drivers/net/macvtap.c | 4 +-- drivers/net/ppp/ppp_async.c | 2 +- drivers/net/ppp/ppp_generic.c | 4 +-- drivers/net/ppp/ppp_synctty.c | 2 +- drivers/net/tun.c | 4 +-- drivers/net/wan/cosa.c | 4 +-- drivers/net/wireless/rt2x00/rt2x00debug.c | 2 +- drivers/platform/goldfish/goldfish_pipe.c | 4 +-- drivers/platform/x86/sony-laptop.c | 2 +- drivers/pps/pps.c | 2 +- drivers/ptp/ptp_chardev.c | 2 +- drivers/ptp/ptp_private.h | 2 +- drivers/rtc/rtc-dev.c | 2 +- drivers/s390/block/dasd_eer.c | 4 +-- drivers/s390/char/monreader.c | 2 +- drivers/scsi/megaraid/megaraid_sas_base.c | 4 +-- drivers/scsi/mpt3sas/mpt3sas_ctl.c | 2 +- drivers/scsi/sg.c | 4 +-- drivers/staging/android/sync.c | 2 +- drivers/staging/comedi/comedi_fops.c | 4 +-- drivers/staging/comedi/drivers/serial2002.c | 2 +- drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +-- drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +- drivers/staging/media/lirc/lirc_parallel.c | 2 +- drivers/staging/media/lirc/lirc_sir.c | 4 +-- drivers/staging/media/lirc/lirc_zilog.c | 4 +-- drivers/staging/media/omap4iss/iss_video.c | 2 +- drivers/staging/most/aim-cdev/cdev.c | 4 +-- drivers/staging/most/aim-v4l2/video.c | 4 +-- drivers/staging/rdma/hfi1/diag.c | 6 ++-- drivers/staging/rdma/hfi1/file_ops.c | 18 +++++------ drivers/staging/rdma/ipath/ipath_file_ops.c | 18 +++++------ drivers/staging/speakup/speakup_soft.c | 4 +-- drivers/tty/n_gsm.c | 4 +-- drivers/tty/n_hdlc.c | 6 ++-- drivers/tty/n_r3964.c | 6 ++-- drivers/tty/n_tty.c | 4 +-- drivers/tty/tty_io.c | 8 ++--- drivers/tty/vt/vc_screen.c | 4 +-- drivers/uio/uio.c | 2 +- drivers/usb/class/cdc-wdm.c | 4 +-- drivers/usb/class/usblp.c | 4 +-- drivers/usb/core/devices.c | 2 +- drivers/usb/core/devio.c | 4 +-- drivers/usb/gadget/function/f_fs.c | 4 +-- drivers/usb/gadget/function/f_hid.c | 4 +-- drivers/usb/gadget/function/f_printer.c | 4 +-- drivers/usb/gadget/function/uvc_queue.c | 2 +- drivers/usb/gadget/function/uvc_queue.h | 2 +- drivers/usb/gadget/function/uvc_v4l2.c | 2 +- drivers/usb/gadget/legacy/inode.c | 4 +-- drivers/usb/misc/iowarrior.c | 4 +-- drivers/usb/misc/ldusb.c | 4 +-- drivers/usb/misc/legousbtower.c | 6 ++-- drivers/usb/mon/mon_bin.c | 4 +-- drivers/vfio/virqfd.c | 4 +-- drivers/vhost/vhost.c | 8 ++--- drivers/vhost/vhost.h | 4 +-- drivers/virt/fsl_hypervisor.c | 4 +-- drivers/xen/evtchn.c | 4 +-- drivers/xen/mcelog.c | 2 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- fs/cachefiles/daemon.c | 10 +++--- fs/coda/psdev.c | 4 +-- fs/dlm/plock.c | 4 +-- fs/dlm/user.c | 2 +- fs/ecryptfs/miscdev.c | 4 +-- fs/eventfd.c | 4 +-- fs/eventpoll.c | 6 ++-- fs/fcntl.c | 4 +-- fs/fuse/dev.c | 4 +-- fs/fuse/file.c | 2 +- fs/fuse/fuse_i.h | 2 +- fs/kernfs/file.c | 2 +- fs/notify/fanotify/fanotify_user.c | 4 +-- fs/notify/inotify/inotify_user.c | 4 +-- fs/ocfs2/dlmfs/dlmfs.c | 4 +-- fs/pipe.c | 4 +-- fs/proc/inode.c | 6 ++-- fs/proc/kmsg.c | 2 +- fs/proc/proc_sysctl.c | 4 +-- fs/proc_namespace.c | 4 +-- fs/select.c | 23 ++++++-------- fs/signalfd.c | 4 +-- fs/timerfd.c | 4 +-- fs/userfaultfd.c | 4 +-- include/drm/drmP.h | 2 +- include/linux/dma-buf.h | 2 +- include/linux/fs.h | 2 +- include/linux/net.h | 2 +- include/linux/poll.h | 10 +++--- include/linux/posix-clock.h | 2 +- include/linux/ring_buffer.h | 2 +- include/linux/scif.h | 4 +-- include/linux/skbuff.h | 4 +-- include/linux/tty_ldisc.h | 2 +- include/linux/wait.h | 10 +++--- include/media/lirc_dev.h | 2 +- include/media/media-devnode.h | 2 +- include/media/soc_camera.h | 2 +- include/media/v4l2-ctrls.h | 2 +- include/media/v4l2-dev.h | 2 +- include/media/v4l2-mem2mem.h | 4 +-- include/media/videobuf-core.h | 2 +- include/media/videobuf2-v4l2.h | 4 +-- include/net/bluetooth/bluetooth.h | 2 +- include/net/inet_connection_sock.h | 2 +- include/net/iucv/af_iucv.h | 4 +-- include/net/sctp/sctp.h | 3 +- include/net/sock.h | 4 +-- include/net/tcp.h | 4 +-- include/net/udp.h | 2 +- include/sound/hwdep.h | 2 +- include/sound/info.h | 2 +- include/uapi/asm-generic/poll.h | 36 +++++++++++++--------- include/uapi/linux/types.h | 6 ++++ ipc/mqueue.c | 4 +-- kernel/events/core.c | 4 +-- kernel/printk/printk.c | 4 +-- kernel/relay.c | 4 +-- kernel/time/posix-clock.c | 4 +-- kernel/trace/ring_buffer.c | 2 +- kernel/trace/trace.c | 6 ++-- mm/memcontrol.c | 2 +- mm/swapfile.c | 2 +- net/atm/common.c | 4 +-- net/atm/common.h | 2 +- net/batman-adv/debugfs.c | 2 +- net/batman-adv/icmp_socket.c | 2 +- net/bluetooth/af_bluetooth.c | 7 ++--- net/caif/caif_socket.c | 6 ++-- net/core/datagram.c | 7 ++--- net/core/sock.c | 2 +- net/dccp/dccp.h | 3 +- net/dccp/proto.c | 5 ++- net/decnet/af_decnet.c | 4 +-- net/ipv4/tcp.c | 4 +-- net/ipv4/udp.c | 4 +-- net/irda/af_irda.c | 6 ++-- net/irda/irnet/irnet_ppp.c | 8 ++--- net/irda/irnet/irnet_ppp.h | 2 +- net/iucv/af_iucv.c | 8 ++--- net/netlink/af_netlink.c | 6 ++-- net/nfc/llcp_sock.c | 8 ++--- net/nfc/nci/uart.c | 2 +- net/packet/af_packet.c | 6 ++-- net/phonet/socket.c | 6 ++-- net/rds/af_rds.c | 6 ++-- net/rfkill/core.c | 4 +-- net/rxrpc/af_rxrpc.c | 6 ++-- net/sctp/socket.c | 4 +-- net/socket.c | 7 ++--- net/sunrpc/cache.c | 10 +++--- net/sunrpc/rpc_pipe.c | 4 +-- net/tipc/socket.c | 6 ++-- net/unix/af_unix.c | 15 ++++----- net/vmw_vsock/af_vsock.c | 6 ++-- security/tomoyo/audit.c | 2 +- security/tomoyo/common.c | 4 +-- security/tomoyo/common.h | 6 ++-- security/tomoyo/securityfs_if.c | 2 +- sound/core/compress_offload.c | 6 ++-- sound/core/control.c | 4 +-- sound/core/hwdep.c | 2 +- sound/core/info.c | 4 +-- sound/core/init.c | 2 +- sound/core/oss/pcm_oss.c | 4 +-- sound/core/pcm_native.c | 8 ++--- sound/core/rawmidi.c | 4 +-- sound/core/seq/oss/seq_oss.c | 4 +-- sound/core/seq/oss/seq_oss_device.h | 2 +- sound/core/seq/oss/seq_oss_rw.c | 4 +-- sound/core/seq/seq_clientmgr.c | 4 +-- sound/core/timer.c | 4 +-- sound/firewire/bebob/bebob_hwdep.c | 4 +-- sound/firewire/dice/dice-hwdep.c | 4 +-- sound/firewire/digi00x/digi00x-hwdep.c | 4 +-- sound/firewire/fireworks/fireworks_hwdep.c | 4 +-- sound/firewire/oxfw/oxfw-hwdep.c | 4 +-- sound/firewire/tascam/tascam-hwdep.c | 4 +-- sound/oss/dmabuf.c | 6 ++-- sound/oss/dmasound/dmasound_core.c | 4 +-- sound/oss/midibuf.c | 4 +-- sound/oss/sequencer.c | 4 +-- sound/oss/sound_calls.h | 6 ++-- sound/oss/soundcard.c | 2 +- sound/oss/swarm_cs4297a.c | 4 +-- sound/usb/mixer_quirks.c | 2 +- sound/usb/usx2y/us122l.c | 4 +-- sound/usb/usx2y/usX2Yhwdep.c | 4 +-- virt/kvm/eventfd.c | 4 +-- 379 files changed, 760 insertions(+), 758 deletions(-) delete mode 100644 arch/alpha/include/uapi/asm/poll.h delete mode 100644 arch/ia64/include/uapi/asm/poll.h delete mode 100644 arch/m32r/include/uapi/asm/poll.h delete mode 100644 arch/microblaze/include/uapi/asm/poll.h delete mode 100644 arch/mn10300/include/uapi/asm/poll.h delete mode 100644 arch/powerpc/include/uapi/asm/poll.h delete mode 100644 arch/s390/include/uapi/asm/poll.h delete mode 100644 arch/score/include/uapi/asm/poll.h delete mode 100644 arch/x86/include/uapi/asm/poll.h ^ permalink raw reply [flat|nested] 12+ messages in thread
* more POLL... fun 2015-11-30 3:04 ` Al Viro @ 2015-12-04 6:38 ` Al Viro 2015-12-04 9:16 ` Arnd Bergmann 0 siblings, 1 reply; 12+ messages in thread From: Al Viro @ 2015-12-04 6:38 UTC (permalink / raw) To: Linus Torvalds; +Cc: Arnd Bergmann, linuxppc-dev On cross-builds the __poll_t annotations had caught something interesting: void spufs_mfc_callback(struct spu *spu) { .... mask = 0; if (free_elements & 0xffff) mask |= POLLOUT; if (tagstatus & ctx->tagwait) mask |= POLLIN; kill_fasync(&ctx->mfc_fasync, SIGIO, mask); .... } That's arch/powerpc/platforms/cell/spufs/file.c. WTF is kill_fasync() getting as the last argument here? Valid values are #define POLL_IN (__SI_POLL|1) /* data input available */ #define POLL_OUT (__SI_POLL|2) /* output buffers available */ #define POLL_MSG (__SI_POLL|3) /* input message available */ #define POLL_ERR (__SI_POLL|4) /* i/o error */ #define POLL_PRI (__SI_POLL|5) /* high priority input available */ #define POLL_HUP (__SI_POLL|6) /* device disconnected */ Use of POLLIN, POLLOUT, etc. here is wrong - kill_fasync() will step into BUG_ON((reason & __SI_MASK) != __SI_POLL); in send_sigio_to_task(). Other two callers of kill_fasync() in that file are trivially fixed by switching to POLL_IN and POLL_OUT; with this one I've no idea what had been intended. What's more, I really wonder if it had _ever_ been tested - these kill_fasync() calls had been introduced in commit 8b3d6663c6217e4f50cc3720935a96da9b984117 Author: Arnd Bergmann <arnd@arndb.de> Date: Tue Nov 15 15:53:52 2005 -0500 [PATCH] spufs: cooperative scheduler support more than 5 years after that BUG_ON() had been added - it goes back to + /* Make sure we are called with one of the POLL_* + reasons, otherwise we could leak kernel stack into + userspace. */ + if ((reason & __SI_MASK) != __SI_POLL) + BUG(); in 2.3.99pre-10-3, on May 25 2000. What the hell am I missing here? Has that code been DOA and never used by anyone in all the decade it had been in mainline? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: more POLL... fun 2015-12-04 6:38 ` more POLL... fun Al Viro @ 2015-12-04 9:16 ` Arnd Bergmann 2015-12-04 15:21 ` Al Viro 0 siblings, 1 reply; 12+ messages in thread From: Arnd Bergmann @ 2015-12-04 9:16 UTC (permalink / raw) To: linuxppc-dev; +Cc: Al Viro, Linus Torvalds On Friday 04 December 2015 06:38:25 Al Viro wrote: > On cross-builds the __poll_t annotations had caught something interesting: > void spufs_mfc_callback(struct spu *spu) > { > .... > mask = 0; > if (free_elements & 0xffff) > mask |= POLLOUT; > if (tagstatus & ctx->tagwait) > mask |= POLLIN; > > kill_fasync(&ctx->mfc_fasync, SIGIO, mask); > .... > } > > That's arch/powerpc/platforms/cell/spufs/file.c. WTF is kill_fasync() > getting as the last argument here? Valid values are > #define POLL_IN (__SI_POLL|1) /* data input available */ > #define POLL_OUT (__SI_POLL|2) /* output buffers available */ > #define POLL_MSG (__SI_POLL|3) /* input message available */ > #define POLL_ERR (__SI_POLL|4) /* i/o error */ > #define POLL_PRI (__SI_POLL|5) /* high priority input available */ > #define POLL_HUP (__SI_POLL|6) /* device disconnected */ > > Use of POLLIN, POLLOUT, etc. here is wrong - kill_fasync() will step into > BUG_ON((reason & __SI_MASK) != __SI_POLL); > in send_sigio_to_task(). Other two callers of kill_fasync() in that file > are trivially fixed by switching to POLL_IN and POLL_OUT; with this one > I've no idea what had been intended. > > What's more, I really wonder if it had _ever_ been tested - these kill_fasync() > calls had been introduced in > commit 8b3d6663c6217e4f50cc3720935a96da9b984117 > Author: Arnd Bergmann <arnd@arndb.de> > Date: Tue Nov 15 15:53:52 2005 -0500 > > [PATCH] spufs: cooperative scheduler support > more than 5 years after that BUG_ON() had been added - it goes back to > + /* Make sure we are called with one of the POLL_* > + reasons, otherwise we could leak kernel stack into > + userspace. */ > + if ((reason & __SI_MASK) != __SI_POLL) > + BUG(); > in 2.3.99pre-10-3, on May 25 2000. > > What the hell am I missing here? Has that code been DOA and never used by > anyone in all the decade it had been in mainline? I don't remember why we put in fasync support, but I have checked the libspe implementation and found that it doesn't use it (not a big surprise there). It always uses epoll() to get notifications from spufs, and based on your explanation I assume everything else (there may have been one or two users that used the low-level interfaces rather than libspe) did too. Arnd ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: more POLL... fun 2015-12-04 9:16 ` Arnd Bergmann @ 2015-12-04 15:21 ` Al Viro 2015-12-04 17:13 ` Arnd Bergmann 0 siblings, 1 reply; 12+ messages in thread From: Al Viro @ 2015-12-04 15:21 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linuxppc-dev, Linus Torvalds On Fri, Dec 04, 2015 at 10:16:50AM +0100, Arnd Bergmann wrote: > I don't remember why we put in fasync support, but I have checked the libspe > implementation and found that it doesn't use it (not a big surprise there). > It always uses epoll() to get notifications from spufs, and based on your > explanation I assume everything else (there may have been one or two users > that used the low-level interfaces rather than libspe) did too. OK... So should we just rip ->{mfc,ibox,wbox}_fasync out, along with all three kill_fasync() and ->fasync() instances in there? We obviously need to leave spufs_{mfc,ibox,wbox}_callback() in place for the sake of those wake_up_all(&ctx->{mfc,ibox,wbox}_wq); in them... I mean, fasync in there obviously never been used at all - it never delivered a single SIGIO, and the first user to try would get the BUG_ON() in fcntl.c instead. Since nobody complained in more than 10 years... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: more POLL... fun 2015-12-04 15:21 ` Al Viro @ 2015-12-04 17:13 ` Arnd Bergmann 2015-12-04 17:30 ` Al Viro 0 siblings, 1 reply; 12+ messages in thread From: Arnd Bergmann @ 2015-12-04 17:13 UTC (permalink / raw) To: Al Viro; +Cc: linuxppc-dev, Linus Torvalds On Friday 04 December 2015 15:21:33 Al Viro wrote: > On Fri, Dec 04, 2015 at 10:16:50AM +0100, Arnd Bergmann wrote: > > > I don't remember why we put in fasync support, but I have checked the libspe > > implementation and found that it doesn't use it (not a big surprise there). > > It always uses epoll() to get notifications from spufs, and based on your > > explanation I assume everything else (there may have been one or two users > > that used the low-level interfaces rather than libspe) did too. > > OK... So should we just rip ->{mfc,ibox,wbox}_fasync out, along with all > three kill_fasync() and ->fasync() instances in there? We obviously need to > leave spufs_{mfc,ibox,wbox}_callback() in place for the sake of those > wake_up_all(&ctx->{mfc,ibox,wbox}_wq); in them... > > I mean, fasync in there obviously never been used at all - it never delivered > a single SIGIO, and the first user to try would get the BUG_ON() in fcntl.c > instead. Since nobody complained in more than 10 years... Yes, I think that would be best. Do you want me to send that patch, or do you prefer to do it yourself? In theory that patch should also go into stable kernels, but I suspect nobody who still owns a machine that is able to run this code will ever upgrade to a stable release, so we probably don't need that. Arnd ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: more POLL... fun 2015-12-04 17:13 ` Arnd Bergmann @ 2015-12-04 17:30 ` Al Viro 2015-12-04 17:34 ` Arnd Bergmann ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Al Viro @ 2015-12-04 17:30 UTC (permalink / raw) To: Arnd Bergmann; +Cc: linuxppc-dev, Linus Torvalds On Fri, Dec 04, 2015 at 06:13:54PM +0100, Arnd Bergmann wrote: > Yes, I think that would be best. Do you want me to send that patch, or do > you prefer to do it yourself? In theory that patch should also go into stable > kernels, but I suspect nobody who still owns a machine that is able to run > this code will ever upgrade to a stable release, so we probably don't need > that. Probably better if it goes through ppc tree - the only relationship it has to VFS is broken calls of kill_fasync() in now-removed code... Something like this, perhaps? [spufs] get rid of broken fasync stuff In all the years it's been in the tree it had never been used by anything - it would instantly trigger BUG_ON() in fs/fcntl.c due to bogus band argument passed to kill_fasync(). Since nobody had ever used it in ten years, let's just rip it out and be done with that. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c index 5038fd5..88b7613 100644 --- a/arch/powerpc/platforms/cell/spufs/file.c +++ b/arch/powerpc/platforms/cell/spufs/file.c @@ -686,23 +686,13 @@ size_t spu_ibox_read(struct spu_context *ctx, u32 *data) return ctx->ops->ibox_read(ctx, data); } -static int spufs_ibox_fasync(int fd, struct file *file, int on) -{ - struct spu_context *ctx = file->private_data; - - return fasync_helper(fd, file, on, &ctx->ibox_fasync); -} - /* interrupt-level ibox callback function. */ void spufs_ibox_callback(struct spu *spu) { struct spu_context *ctx = spu->ctx; - if (!ctx) - return; - - wake_up_all(&ctx->ibox_wq); - kill_fasync(&ctx->ibox_fasync, SIGIO, POLLIN); + if (ctx) + wake_up_all(&ctx->ibox_wq); } /* @@ -797,7 +787,6 @@ static const struct file_operations spufs_ibox_fops = { .open = spufs_pipe_open, .read = spufs_ibox_read, .poll = spufs_ibox_poll, - .fasync = spufs_ibox_fasync, .llseek = no_llseek, }; @@ -835,26 +824,13 @@ size_t spu_wbox_write(struct spu_context *ctx, u32 data) return ctx->ops->wbox_write(ctx, data); } -static int spufs_wbox_fasync(int fd, struct file *file, int on) -{ - struct spu_context *ctx = file->private_data; - int ret; - - ret = fasync_helper(fd, file, on, &ctx->wbox_fasync); - - return ret; -} - /* interrupt-level wbox callback function. */ void spufs_wbox_callback(struct spu *spu) { struct spu_context *ctx = spu->ctx; - if (!ctx) - return; - - wake_up_all(&ctx->wbox_wq); - kill_fasync(&ctx->wbox_fasync, SIGIO, POLLOUT); + if (ctx) + wake_up_all(&ctx->wbox_wq); } /* @@ -947,7 +923,6 @@ static const struct file_operations spufs_wbox_fops = { .open = spufs_pipe_open, .write = spufs_wbox_write, .poll = spufs_wbox_poll, - .fasync = spufs_wbox_fasync, .llseek = no_llseek, }; @@ -1523,28 +1498,8 @@ void spufs_mfc_callback(struct spu *spu) { struct spu_context *ctx = spu->ctx; - if (!ctx) - return; - - wake_up_all(&ctx->mfc_wq); - - pr_debug("%s %s\n", __func__, spu->name); - if (ctx->mfc_fasync) { - u32 free_elements, tagstatus; - unsigned int mask; - - /* no need for spu_acquire in interrupt context */ - free_elements = ctx->ops->get_mfc_free_elements(ctx); - tagstatus = ctx->ops->read_mfc_tagstatus(ctx); - - mask = 0; - if (free_elements & 0xffff) - mask |= POLLOUT; - if (tagstatus & ctx->tagwait) - mask |= POLLIN; - - kill_fasync(&ctx->mfc_fasync, SIGIO, mask); - } + if (ctx) + wake_up_all(&ctx->mfc_wq); } static int spufs_read_mfc_tagstatus(struct spu_context *ctx, u32 *status) @@ -1806,13 +1761,6 @@ static int spufs_mfc_fsync(struct file *file, loff_t start, loff_t end, int data return err; } -static int spufs_mfc_fasync(int fd, struct file *file, int on) -{ - struct spu_context *ctx = file->private_data; - - return fasync_helper(fd, file, on, &ctx->mfc_fasync); -} - static const struct file_operations spufs_mfc_fops = { .open = spufs_mfc_open, .release = spufs_mfc_release, @@ -1821,7 +1769,6 @@ static const struct file_operations spufs_mfc_fops = { .poll = spufs_mfc_poll, .flush = spufs_mfc_flush, .fsync = spufs_mfc_fsync, - .fasync = spufs_mfc_fasync, .mmap = spufs_mfc_mmap, .llseek = no_llseek, }; diff --git a/arch/powerpc/platforms/cell/spufs/spufs.h b/arch/powerpc/platforms/cell/spufs/spufs.h index bcfd6f0..aac7339 100644 --- a/arch/powerpc/platforms/cell/spufs/spufs.h +++ b/arch/powerpc/platforms/cell/spufs/spufs.h @@ -102,9 +102,6 @@ struct spu_context { wait_queue_head_t stop_wq; wait_queue_head_t mfc_wq; wait_queue_head_t run_wq; - struct fasync_struct *ibox_fasync; - struct fasync_struct *wbox_fasync; - struct fasync_struct *mfc_fasync; u32 tagwait; struct spu_context_ops *ops; struct work_struct reap_work; ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: more POLL... fun 2015-12-04 17:30 ` Al Viro @ 2015-12-04 17:34 ` Arnd Bergmann 2015-12-06 23:58 ` Michael Ellerman 2017-02-16 5:59 ` Michael Ellerman 2 siblings, 0 replies; 12+ messages in thread From: Arnd Bergmann @ 2015-12-04 17:34 UTC (permalink / raw) To: Al Viro; +Cc: linuxppc-dev, Linus Torvalds, mpe On Friday 04 December 2015 17:30:31 Al Viro wrote: > On Fri, Dec 04, 2015 at 06:13:54PM +0100, Arnd Bergmann wrote: > > > Yes, I think that would be best. Do you want me to send that patch, or do > > you prefer to do it yourself? In theory that patch should also go into stable > > kernels, but I suspect nobody who still owns a machine that is able to run > > this code will ever upgrade to a stable release, so we probably don't need > > that. > > Probably better if it goes through ppc tree - the only relationship it has > to VFS is broken calls of kill_fasync() in now-removed code... Right. > Something like this, perhaps? > > [spufs] get rid of broken fasync stuff > > In all the years it's been in the tree it had never been used by > anything - it would instantly trigger BUG_ON() in fs/fcntl.c due > to bogus band argument passed to kill_fasync(). Since nobody > had ever used it in ten years, let's just rip it out and be > done with that. > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> > --- Looks all good, thanks! Acked-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: more POLL... fun 2015-12-04 17:30 ` Al Viro 2015-12-04 17:34 ` Arnd Bergmann @ 2015-12-06 23:58 ` Michael Ellerman 2017-02-16 5:59 ` Michael Ellerman 2 siblings, 0 replies; 12+ messages in thread From: Michael Ellerman @ 2015-12-06 23:58 UTC (permalink / raw) To: Al Viro, Arnd Bergmann; +Cc: Linus Torvalds, linuxppc-dev On Fri, 2015-12-04 at 17:30 +0000, Al Viro wrote: > On Fri, Dec 04, 2015 at 06:13:54PM +0100, Arnd Bergmann wrote: > > Yes, I think that would be best. Do you want me to send that patch, or do > > you prefer to do it yourself? In theory that patch should also go into stable > > kernels, but I suspect nobody who still owns a machine that is able to run > > this code will ever upgrade to a stable release, so we probably don't need > > that. > > Probably better if it goes through ppc tree - the only relationship it has > to VFS is broken calls of kill_fasync() in now-removed code... Something > like this, perhaps? Yeah that looks fine to me. I'll take it into powerpc#next for 4.5. cheers ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: more POLL... fun 2015-12-04 17:30 ` Al Viro 2015-12-04 17:34 ` Arnd Bergmann 2015-12-06 23:58 ` Michael Ellerman @ 2017-02-16 5:59 ` Michael Ellerman 2 siblings, 0 replies; 12+ messages in thread From: Michael Ellerman @ 2017-02-16 5:59 UTC (permalink / raw) To: Al Viro, Arnd Bergmann; +Cc: Linus Torvalds, linuxppc-dev On Fri, 2015-12-04 at 17:30:31 UTC, Al Viro wrote: > On Fri, Dec 04, 2015 at 06:13:54PM +0100, Arnd Bergmann wrote: > > > Yes, I think that would be best. Do you want me to send that patch, or do > > you prefer to do it yourself? In theory that patch should also go into stable > > kernels, but I suspect nobody who still owns a machine that is able to run > > this code will ever upgrade to a stable release, so we probably don't need > > that. > > Probably better if it goes through ppc tree - the only relationship it has > to VFS is broken calls of kill_fasync() in now-removed code... Something > like this, perhaps? > > [spufs] get rid of broken fasync stuff > > In all the years it's been in the tree it had never been used by > anything - it would instantly trigger BUG_ON() in fs/fcntl.c due > to bogus band argument passed to kill_fasync(). Since nobody > had ever used it in ten years, let's just rip it out and be > done with that. > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> > Acked-by: Arnd Bergmann <arnd@arndb.de> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/7d7be3aa08fa338e84eb235805ee18 cheers ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-02-16 5:59 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-11-27 5:00 ->poll() instances shouldn't be indefinitely blocking Al Viro 2015-11-27 15:18 ` Mauro Carvalho Chehab 2015-11-27 17:49 ` Linus Torvalds 2015-11-30 3:04 ` Al Viro 2015-12-04 6:38 ` more POLL... fun Al Viro 2015-12-04 9:16 ` Arnd Bergmann 2015-12-04 15:21 ` Al Viro 2015-12-04 17:13 ` Arnd Bergmann 2015-12-04 17:30 ` Al Viro 2015-12-04 17:34 ` Arnd Bergmann 2015-12-06 23:58 ` Michael Ellerman 2017-02-16 5:59 ` Michael Ellerman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.