| Age | Commit message (Collapse) | Author |
|---|
|
Fix those warnings:
drivers/media/platform/mtk-vpu/mtk_vpu.c:223: warning: No description found for parameter 'wdt'
drivers/media/platform/mtk-vpu/mtk_vpu.c:223: warning: No description found for parameter 'wdt_refcnt'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Fix those warnings:
drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c:69: warning: No description found for parameter 'reserved'
drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_if.c:175: warning: Excess struct member 'dev' description in 'vdec_vp8_inst'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There are some struct fields that aren't documented, and some
consts whose comments start with /**, but they aren't kernel-doc
annotations. So, fix it:
drivers/media/i2c/tvp514x.c:127: warning: No description found for parameter 'hdl'
drivers/media/i2c/tvp514x.c:127: warning: No description found for parameter 'pad'
drivers/media/i2c/tvp514x.c:127: warning: No description found for parameter 'format'
drivers/media/i2c/tvp514x.c:127: warning: No description found for parameter 'int_seq'
drivers/media/i2c/tvp514x.c:219: warning: cannot understand function prototype: 'const struct v4l2_fmtdesc tvp514x_fmt_list[] = '
drivers/media/i2c/tvp514x.c:235: warning: cannot understand function prototype: 'const struct tvp514x_std_info tvp514x_std_list[] = '
drivers/media/i2c/tvp514x.c:941: warning: No description found for parameter 'fmt'
drivers/media/i2c/tvp514x.c:941: warning: Excess function parameter 'format' description in 'tvp514x_set_pad_format'
drivers/media/i2c/tvp514x.c:1208: warning: cannot understand function prototype: 'const struct i2c_device_id tvp514x_id[] = '
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There is a bad kernel-doc markup, producing the following warnings:
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:85: warning: bad line: Bits [0-7]: DMA packet size, 188 bytes
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:86: warning: bad line: Bits [16-23]: packets count in block, 128 packets
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:87: warning: bad line: Bits [24-31]: blocks count, 8 blocks
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:89: warning: bad line: For example, value of 375000000 equals to 3 sec
Fix that, and use a list for the bits option, in order for it
to be better format, if we add it to a driver's documentation
file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
as warned:
drivers/media/i2c/s5k6aa.c:429: warning: No description found for parameter 's5k6aa'
drivers/media/i2c/s5k6aa.c:679: warning: No description found for parameter 's5k6aa'
drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 's5k6aa'
drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 'preset'
drivers/media/i2c/s5k6aa.c:787: warning: No description found for parameter 'sd'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
drivers/media/i2c/s5k6a3.c:68: warning: No description found for parameter 'clock'
drivers/media/i2c/s5k6a3.c:68: warning: No description found for parameter 'clock_frequency'
drivers/media/i2c/s5k6a3.c:68: warning: No description found for parameter 'power_count'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
get rid of the following warnings:
drivers/media/radio/radio-si476x.c:317: warning: No description found for parameter 'v4l2dev'
drivers/media/radio/radio-si476x.c:317: warning: No description found for parameter 'ctrl_handler'
drivers/media/radio/radio-si476x.c:317: warning: No description found for parameter 'debugfs'
drivers/media/radio/radio-si476x.c:317: warning: No description found for parameter 'audmode'
drivers/media/radio/radio-si476x.c:317: warning: Excess struct member 'kref' description in 'si476x_radio'
drivers/media/radio/radio-si476x.c:317: warning: Excess struct member 'core_lock' description in 'si476x_radio'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
As warned:
drivers/media/dvb-frontends/ix2505v.c:24: warning: cannot understand function prototype: 'int ix2505v_debug; '
drivers/media/dvb-frontends/ix2505v.c:59: warning: No description found for parameter 'state'
drivers/media/dvb-frontends/ix2505v.c:128: warning: No description found for parameter 'fe'
None of the comments there are kernel-doc. So, remove them with:
perl -pi -e 's,\/\*\*,/*,g' drivers/media/dvb-frontends/ix2505v.c
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There are a few mistakes on the existing markups:
drivers/media/pci/tw68/tw68-risc.c:32: warning: Cannot understand * @rp pointer to current risc program position
on line 32 - I thought it was a doc line
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'pci'
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'buf'
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'sglist'
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'top_offset'
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'bottom_offset'
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'bpl'
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'padding'
drivers/media/pci/tw68/tw68-risc.c:144: warning: No description found for parameter 'lines'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Get rid of the following warnings:
drivers/media/platform/pxa_camera.c:247: warning: No description found for parameter 'layout'
drivers/media/platform/pxa_camera.c:867: warning: No description found for parameter 'buf'
drivers/media/platform/pxa_camera.c:867: warning: No description found for parameter 'sg'
drivers/media/platform/pxa_camera.c:867: warning: No description found for parameter 'sglen'
drivers/media/platform/pxa_camera.c:867: warning: Excess function parameter 'vb' description in 'pxa_init_dma_channel'
drivers/media/platform/pxa_camera.c:867: warning: Excess function parameter 'dma' description in 'pxa_init_dma_channel'
drivers/media/platform/pxa_camera.c:867: warning: Excess function parameter 'cibr' description in 'pxa_init_dma_channel'
drivers/media/platform/pxa_camera.c:1029: warning: No description found for parameter 'last_submitted'
drivers/media/platform/pxa_camera.c:1029: warning: No description found for parameter 'last_issued'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
As warned:
drivers/media/pci/sta2x11/sta2x11_vip.c:414: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:442: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:476: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:493: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:524: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:548: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:566: warning: No description found for parameter 'file'
drivers/media/pci/sta2x11/sta2x11_vip.c:566: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:594: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:651: warning: No description found for parameter 'priv'
drivers/media/pci/sta2x11/sta2x11_vip.c:717: warning: No description found for parameter 'priv'
Most of the above are for the unused priv argument.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Fix those warnings:
drivers/media/i2c/m5mols/m5mols_capture.c:42: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_capture.c:42: warning: No description found for parameter 'addr_num'
drivers/media/i2c/m5mols/m5mols_capture.c:42: warning: No description found for parameter 'addr_den'
drivers/media/i2c/m5mols/m5mols_capture.c:42: warning: No description found for parameter 'val'
drivers/media/i2c/m5mols/m5mols_capture.c:60: warning: No description found for parameter 'info'
drivers/media/i2c/m5mols/m5mols_controls.c:134: warning: No description found for parameter 'info'
drivers/media/i2c/m5mols/m5mols_core.c:124: warning: No description found for parameter 'data'
drivers/media/i2c/m5mols/m5mols_core.c:124: warning: No description found for parameter 'length'
drivers/media/i2c/m5mols/m5mols_core.c:124: warning: Excess function parameter 'size' description in 'm5mols_swap_byte'
drivers/media/i2c/m5mols/m5mols_core.c:142: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:241: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:299: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:324: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:324: warning: No description found for parameter 'reg'
drivers/media/i2c/m5mols/m5mols_core.c:357: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:357: warning: No description found for parameter 'mode'
drivers/media/i2c/m5mols/m5mols_core.c:374: warning: No description found for parameter 'info'
drivers/media/i2c/m5mols/m5mols_core.c:429: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:503: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:671: warning: No description found for parameter 'info'
drivers/media/i2c/m5mols/m5mols_core.c:694: warning: No description found for parameter 'info'
drivers/media/i2c/m5mols/m5mols_core.c:798: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:853: warning: No description found for parameter 'sd'
drivers/media/i2c/m5mols/m5mols_core.c:853: warning: No description found for parameter 'on'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Fix those kernel-doc warnings:
drivers/media/platform/exynos4-is/mipi-csis.c:229: warning: No description found for parameter 'clk_frequency'
drivers/media/platform/exynos4-is/mipi-csis.c:229: warning: Excess struct member 'clock_frequency' description in 'csis_state'
drivers/media/platform/exynos4-is/media-dev.c:69: warning: No description found for parameter 'p'
drivers/media/platform/exynos4-is/media-dev.c:160: warning: No description found for parameter 'p'
drivers/media/platform/exynos4-is/media-dev.c:160: warning: No description found for parameter 'on'
drivers/media/platform/exynos4-is/media-dev.c:160: warning: Excess function parameter 'fimc' description in 'fimc_pipeline_s_power'
drivers/media/platform/exynos4-is/media-dev.c:160: warning: Excess function parameter 'state' description in 'fimc_pipeline_s_power'
drivers/media/platform/exynos4-is/media-dev.c:229: warning: No description found for parameter 'ep'
drivers/media/platform/exynos4-is/media-dev.c:260: warning: No description found for parameter 'ep'
drivers/media/platform/exynos4-is/media-dev.c:260: warning: Excess function parameter 'fimc' description in '__fimc_pipeline_close'
drivers/media/platform/exynos4-is/media-dev.c:288: warning: No description found for parameter 'ep'
drivers/media/platform/exynos4-is/media-dev.c:288: warning: Excess function parameter 'pipeline' description in '__fimc_pipeline_s_stream'
drivers/media/platform/exynos4-is/media-dev.c:916: warning: No description found for parameter 'fmd'
drivers/media/platform/exynos4-is/fimc-capture.c:155: warning: No description found for parameter 'ctx'
drivers/media/platform/exynos4-is/fimc-capture.c:868: warning: No description found for parameter 'num_planes'
drivers/media/platform/exynos4-is/fimc-capture.c:1108: warning: No description found for parameter 'fimc'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There are no descriptions for some enums, with produces lots
of warnings:
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_LUMA' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_LUMA2' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_LUMA3' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_CHROMA' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_CHROMA2' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_CHROMA3' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_MV_INFO' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_BS_HEADER' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_PROB_BUF' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_RC_INFO' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_RC_CODE' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_RC_CODE2' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_RC_CODE3' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:55: warning: Enum value 'VENC_VP8_VPU_WORK_BUF_MAX' not described in enum 'venc_vp8_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_RC_INFO' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_RC_CODE' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_REC_LUMA' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_REC_CHROMA' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_REF_LUMA' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_REF_CHROMA' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_MV_INFO_1' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_MV_INFO_2' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_SKIP_FRAME' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:51: warning: Enum value 'VENC_H264_VPU_WORK_BUF_MAX' not described in enum 'venc_h264_vpu_work_buf'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:60: warning: Enum value 'H264_BS_MODE_SPS' not described in enum 'venc_h264_bs_mode'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:60: warning: Enum value 'H264_BS_MODE_PPS' not described in enum 'venc_h264_bs_mode'
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c:60: warning: Enum value 'H264_BS_MODE_FRAME' not described in enum 'venc_h264_bs_mode'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There are several of kernel-doc warnings:
drivers/media/platform/davinci/vpif_display.c:114: warning: No description found for parameter 'sizes'
drivers/media/platform/davinci/vpif_display.c:165: warning: No description found for parameter 'vq'
drivers/media/platform/davinci/vpif_display.c:165: warning: Excess function parameter 'vb' description in 'vpif_start_streaming'
drivers/media/platform/davinci/vpif_display.c:780: warning: No description found for parameter 'vpif_cfg'
drivers/media/platform/davinci/vpif_display.c:780: warning: No description found for parameter 'chan_cfg'
drivers/media/platform/davinci/vpif_display.c:780: warning: No description found for parameter 'index'
drivers/media/platform/davinci/vpif_display.c:813: warning: No description found for parameter 'vpif_cfg'
drivers/media/platform/davinci/vpif_display.c:813: warning: No description found for parameter 'ch'
drivers/media/platform/davinci/vpif_display.c:813: warning: No description found for parameter 'index'
drivers/media/platform/davinci/vpif_capture.c:121: warning: No description found for parameter 'sizes'
drivers/media/platform/davinci/vpif_capture.c:174: warning: No description found for parameter 'vq'
drivers/media/platform/davinci/vpif_capture.c:174: warning: Excess function parameter 'vb' description in 'vpif_start_streaming'
drivers/media/platform/davinci/vpif_capture.c:636: warning: No description found for parameter 'iface'
drivers/media/platform/davinci/vpif_capture.c:647: warning: No description found for parameter 'ch'
drivers/media/platform/davinci/vpif_capture.c:647: warning: No description found for parameter 'muxmode'
drivers/media/platform/davinci/vpif_capture.c:676: warning: No description found for parameter 'vpif_cfg'
drivers/media/platform/davinci/vpif_capture.c:676: warning: No description found for parameter 'chan_cfg'
drivers/media/platform/davinci/vpif_capture.c:676: warning: No description found for parameter 'input_index'
drivers/media/platform/davinci/vpif_capture.c:712: warning: No description found for parameter 'vpif_cfg'
drivers/media/platform/davinci/vpif_capture.c:712: warning: No description found for parameter 'ch'
drivers/media/platform/davinci/vpif_capture.c:712: warning: No description found for parameter 'index'
drivers/media/platform/davinci/vpif_capture.c:798: warning: No description found for parameter 'std'
drivers/media/platform/davinci/vpif_capture.c:798: warning: Excess function parameter 'std_id' description in 'vpif_g_std'
drivers/media/platform/davinci/vpif_capture.c:940: warning: No description found for parameter 'fmt'
drivers/media/platform/davinci/vpif_capture.c:940: warning: Excess function parameter 'index' description in 'vpif_enum_fmt_vid_cap'
drivers/media/platform/davinci/vpif_capture.c:1750: warning: No description found for parameter 'dev'
Fix them.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There are some troubles on kernel-doc markups, as warned:
drivers/media/v4l2-core/v4l2-dv-timings.c:259: warning: No description found for parameter 't1'
drivers/media/v4l2-core/v4l2-dv-timings.c:259: warning: No description found for parameter 't2'
drivers/media/v4l2-core/v4l2-dv-timings.c:259: warning: No description found for parameter 'pclock_delta'
drivers/media/v4l2-core/v4l2-dv-timings.c:259: warning: No description found for parameter 'match_reduced_fps'
drivers/media/v4l2-core/tuner-core.c:242: warning: bad line: internal parameters, like LNA mode
drivers/media/v4l2-core/tuner-core.c:765: warning: No description found for parameter 'mode'
drivers/media/v4l2-core/videobuf2-memops.c:127: warning: cannot understand function prototype: 'const struct vm_operations_struct vb2_common_vm_ops = '
drivers/media/v4l2-core/v4l2-mem2mem.c:190: warning: No description found for parameter 'm2m_dev'
drivers/media/v4l2-core/v4l2-mem2mem.c:291: warning: No description found for parameter 'm2m_ctx'
drivers/media/v4l2-core/videobuf-core.c:233: warning: No description found for parameter 'q'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There are several parameters there that are named wrong, as
reported by those warnings:
drivers/media/rc/ir-sharp-decoder.c:47: warning: No description found for parameter 'ev'
drivers/media/rc/ir-sharp-decoder.c:47: warning: Excess function parameter 'duration' description in 'ir_sharp_decode'
drivers/media/rc/ir-sanyo-decoder.c:56: warning: No description found for parameter 'ev'
drivers/media/rc/ir-sanyo-decoder.c:56: warning: Excess function parameter 'duration' description in 'ir_sanyo_decode'
drivers/media/rc/ir-xmp-decoder.c:43: warning: No description found for parameter 'ev'
drivers/media/rc/ir-xmp-decoder.c:43: warning: Excess function parameter 'duration' description in 'ir_xmp_decode'
drivers/media/rc/ir-jvc-decoder.c:47: warning: No description found for parameter 'ev'
drivers/media/rc/ir-jvc-decoder.c:47: warning: Excess function parameter 'duration' description in 'ir_jvc_decode'
drivers/media/rc/ir-lirc-codec.c:34: warning: No description found for parameter 'dev'
drivers/media/rc/ir-lirc-codec.c:34: warning: No description found for parameter 'ev'
drivers/media/rc/ir-lirc-codec.c:34: warning: Excess function parameter 'input_dev' description in 'ir_lirc_decode'
drivers/media/rc/ir-lirc-codec.c:34: warning: Excess function parameter 'duration' description in 'ir_lirc_decode'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
A recent change on Kernel 4.15-rc1 causes all tags with
/** to be handled as kernel-doc markups. Well, several
atomisp modules, it doesn't use kernel-doc, but some other
documentation markup (doxygen?).
So, suppress all those warns by:
- replacing /**< by /**.
- replacing /** by /*.
The core changes were done with:
for i in $(find drivers/staging/media/atomisp -type f); do sed 's,/\*\* ,/\*, ' -i $i; done
for i in $(find drivers/staging/media/atomisp -type f); do sed 's,/\*\*<,/\**,' -i $i; done
for i in drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/rmgr/src/rmgr_vbuf.c; do perl -ne 's,\/\*\*$,/*,g; print $_' $i > a && mv a $i; done;
A few manual adjustments were made, where needed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
The use of snd_BUG_ON() in ALSA sequencer timer may lead to a spurious
WARN_ON() when a slave timer is deployed as its backend and a
corresponding master timer stops meanwhile. The symptom was triggered
by syzkaller spontaneously.
Since the NULL timer is valid there, rip off snd_BUG_ON().
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We seem to be missing some W/A for 2M pages and are getting
a hit on raw GPU read bandwidths (even 30%) even though the
GPU write bandwidths improve (even 10%).
For now, disable THP, which is our only practical source of
2M pages until we have a W/A for the issue.
v2:
- Be explicit that we talk about GPU bandwidths (Eero)
- s/deny/never/ because that's why (Chris)
Reported-by: Valtteri Rantala <valtteri.rantala@intel.com>
Fixes: b901bb89324a ("drm/i915/gemfs: enable THP")
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Valtteri Rantala <valtteri.rantala@intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Tested-by: Valtteri Rantala <valtteri.rantala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171127091233.7001-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit 9987da4b5dcfc8b94b702d4bb94b30955eb73c75)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Use drm_dp_channel_eq_ok helper
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-7-git-send-email-andrey.gusakov@cogentembedded.com
|
|
First four bytes should go to DP0_AUXWDATA0. Due to bug if
len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
data get shifted by 4 bytes. Fix it.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-6-git-send-email-andrey.gusakov@cogentembedded.com
|
|
Fields in HTIM01 and HTIM02 regs should be even.
Recomended thresh_dly value is max_tu_symbol.
Remove set of VPCTRL0.VSDELAY as it is related to DSI input
interface. Currently driver supports only DPI.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-5-git-send-email-andrey.gusakov@cogentembedded.com
|
|
Remove shift from TU_SIZE_RECOMMENDED define as it used to
calculate max_tu_symbols.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-4-git-send-email-andrey.gusakov@cogentembedded.com
|
|
Pixel clock limitation for DPI is 154 MHz. Do not accept modes
with higher pixel clock rate.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-3-git-send-email-andrey.gusakov@cogentembedded.com
|
|
Do not fail data rates higher than 2.7 and more than 2 lanes.
Try to fall back to 2.7Gbps and 2 lanes.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-2-git-send-email-andrey.gusakov@cogentembedded.com
|
|
The panel_bridge bridge attaches to the panel's OF node, not the
lvds-encoder's node. Put in a little no-op bridge of our own so that
our consumers can still find a bridge where they expect.
This also fixes an unintended unregistration and leak of the
panel-bridge on module remove.
Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bri
dge.")
Tested-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114191647.22207-1-eric@anholt.net
|
|
Support the "cec" optional clock. The documentation already mentions "cec"
optional clock and it is used by several boards, but currently the driver
doesn't enable it, thus preventing cec from working on those boards.
And even worse: a /dev/cecX device will appear for those boards, but it
won't be functioning without configuring this clock.
Changes:
v4:
- Change commit message to stress the importance of this patch
v3:
- Drop useless braces
v2:
- Separate ENOENT errors from others
- Propagate other errors (especially -EPROBE_DEFER)
Signed-off-by: Pierre-Hugues Husson <phh@phh.me>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125201844.11353-1-phh@phh.me
|
|
If the device tree for a board did not specify a cec clock, then
adv7511_cec_init would return an error, which would cause adv7511_probe()
to fail and thus there is no HDMI output.
There is no need to have adv7511_probe() fail if the CEC initialization
fails, so just change adv7511_cec_init() to a void function. In addition,
adv7511_cec_init() should just return silently if the cec clock isn't
found and show a message for any other errors.
An otherwise correct cleanup patch from Dan Carpenter turned this broken
failure handling into a kernel Oops, so bisection points to commit
7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
than 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support").
Based on earlier patches from Arnd and John.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Xinliang Liu <xinliang.liu@linaro.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>
Link: https://bugs.linaro.org/show_bug.cgi?id=3345
Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/9097b2a4-b6b9-5fca-e039-0a17694b1143@xs4all.nl
|
|
Mergr misc fixes from Andrew Morton:
"28 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (28 commits)
fs/hugetlbfs/inode.c: change put_page/unlock_page order in hugetlbfs_fallocate()
mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
autofs: revert "autofs: take more care to not update last_used on path walk"
fs/fat/inode.c: fix sb_rdonly() change
mm, memcg: fix mem_cgroup_swapout() for THPs
mm: migrate: fix an incorrect call of prep_transhuge_page()
kmemleak: add scheduling point to kmemleak_scan()
scripts/bloat-o-meter: don't fail with division by 0
fs/mbcache.c: make count_objects() more robust
Revert "mm/page-writeback.c: print a warning if the vm dirtiness settings are illogical"
mm/madvise.c: fix madvise() infinite loop under special circumstances
exec: avoid RLIMIT_STACK races with prlimit()
IB/core: disable memory registration of filesystem-dax vmas
v4l2: disable filesystem-dax mapping support
mm: fail get_vaddr_frames() for filesystem-dax mappings
mm: introduce get_user_pages_longterm
device-dax: implement ->split() to catch invalid munmap attempts
mm, hugetlbfs: introduce ->split() to vm_operations_struct
scripts/faddr2line: extend usage on generic arch
...
|
|
hugetlfs_fallocate() currently performs put_page() before unlock_page().
This scenario opens a small time window, from the time the page is added
to the page cache, until it is unlocked, in which the page might be
removed from the page-cache by another core. If the page is removed
during this time windows, it might cause a memory corruption, as the
wrong page will be unlocked.
It is arguable whether this scenario can happen in a real system, and
there are several mitigating factors. The issue was found by code
inspection (actually grep), and not by actually triggering the flow.
Yet, since putting the page before unlocking is incorrect it should be
fixed, if only to prevent future breakage or someone copy-pasting this
code.
Mike said:
"I am of the opinion that this does not need to be sent to stable.
Although the ordering is current code is incorrect, there is no way
for this to be a problem with current locking. In addition, I verified
that the perhaps bigger issue with sys_fadvise64(POSIX_FADV_DONTNEED)
for hugetlbfs and other filesystems is addressed in 3a77d214807c ("mm:
fadvise: avoid fadvise for fs without backing device")"
Link: http://lkml.kernel.org/r/20170826191124.51642-1-namit@vmware.com
Fixes: 70c3547e36f5c ("hugetlbfs: add hugetlbfs_fallocate()")
Signed-off-by: Nadav Amit <namit@vmware.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Eric Biggers <ebiggers3@gmail.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
I made a mistake during converting hugetlb code to 5-level paging: in
huge_pte_alloc() we have to use p4d_alloc(), not p4d_offset().
Otherwise it leads to crash -- NULL-pointer dereference in pud_alloc()
if p4d table is not yet allocated.
It only can happen in 5-level paging mode. In 4-level paging mode
p4d_offset() always returns pgd, so we are fine.
Link: http://lkml.kernel.org/r/20171122121921.64822-1-kirill.shutemov@linux.intel.com
Fixes: c2febafc6773 ("mm: convert generic code to 5-level paging")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Commit 42f461482178 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
allowed the fstatat(2) system call to properly honor the AT_NO_AUTOMOUNT
flag but introduced a semantic change.
In order to honor AT_NO_AUTOMOUNT a semantic change was made to the
negative dentry case for stat family system calls in follow_automount().
This changed the unconditional triggering of an automount in this case
to no longer be done and an error returned instead.
This has caused more problems than I expected so reverting the change is
needed.
In a discussion with Neil Brown it was concluded that the automount(8)
daemon can implement this change without kernel modifications. So that
will be done instead and the autofs module documentation updated with a
description of the problem and what needs to be done by module users for
this specific case.
Link: http://lkml.kernel.org/r/151174730120.6162.3848002191530283984.stgit@pluto.themaw.net
Fixes: 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
Signed-off-by: Ian Kent <raven@themaw.net>
Cc: Neil Brown <neilb@suse.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: David Howells <dhowells@redhat.com>
Cc: Colin Walters <walters@redhat.com>
Cc: Ondrej Holy <oholy@redhat.com>
Cc: <stable@vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
While commit 092a53452bb7 ("autofs: take more care to not update
last_used on path walk") helped (partially) resolve a problem where
automounts were not expiring due to aggressive accesses from user space
it has a side effect for very large environments.
This change helps with the expire problem by making the expire more
aggressive but, for very large environments, that means more mount
requests from clients. When there are a lot of clients that can mean
fairly significant server load increases.
It turns out I put the last_used in this position to solve this very
problem and failed to update my own thinking of the autofs expire
policy. So the patch being reverted introduces a regression which
should be fixed.
Link: http://lkml.kernel.org/r/151174729420.6162.1832622523537052460.stgit@pluto.themaw.net
Fixes: 092a53452b ("autofs: take more care to not update last_used on path walk")
Signed-off-by: Ian Kent <raven@themaw.net>
Reviewed-by: NeilBrown <neilb@suse.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: <stable@vger.kernel.org> [4.11+]
Cc: Colin Walters <walters@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ondrej Holy <oholy@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Commit bc98a42c1f7d ("VFS: Convert sb->s_flags & MS_RDONLY to
sb_rdonly(sb)") converted fat_remount():new_rdonly from a bool to an
int.
However fat_remount() depends upon the compiler's conversion of a
non-zero integer into boolean `true'.
Fix it by switching `new_rdonly' back into a bool.
Link: http://lkml.kernel.org/r/87mv3d5x51.fsf@mail.parknet.co.jp
Fixes: bc98a42c1f7d0f8 ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Joe Perches <joe@perches.com>
Cc: David Howells <dhowells@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Commit d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout()
support THP") changed mem_cgroup_swapout() to support transparent huge
page (THP).
However the patch missed one location which should be changed for
correctly handling THPs. The resulting bug will cause the memory
cgroups whose THPs were swapped out to become zombies on deletion.
Link: http://lkml.kernel.org/r/20171128161941.20931-1-shakeelb@google.com
Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
Signed-off-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
In https://lkml.org/lkml/2017/11/20/411, Andrea reported that during
memory hotplug/hot remove prep_transhuge_page() is called incorrectly on
non-THP pages for migration, when THP is on but THP migration is not
enabled. This leads to a bad state of target pages for migration.
By inspecting the code, if called on a non-THP, prep_transhuge_page()
will
1) change the value of the mapping of (page + 2), since it is used for
THP deferred list;
2) change the lru value of (page + 1), since it is used for THP's dtor.
Both can lead to data corruption of these two pages.
Andrea said:
"Pragmatically and from the point of view of the memory_hotplug subsys,
the effect is a kernel crash when pages are being migrated during a
memory hot remove offline and migration target pages are found in a
bad state"
This patch fixes it by only calling prep_transhuge_page() when we are
certain that the target page is THP.
Link: http://lkml.kernel.org/r/20171121021855.50525-1-zi.yan@sent.com
Fixes: 8135d8926c08 ("mm: memory_hotplug: memory hotremove supports thp migration")
Signed-off-by: Zi Yan <zi.yan@cs.rutgers.edu>
Reported-by: Andrea Reale <ar@linux.vnet.ibm.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: <stable@vger.kernel.org> [4.14]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
kmemleak_scan() will scan struct page for each node and it can be really
large and resulting in a soft lockup. We have seen a soft lockup when
do scan while compile kernel:
watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287]
[...]
Call Trace:
kmemleak_scan+0x21a/0x4c0
kmemleak_write+0x312/0x350
full_proxy_write+0x5a/0xa0
__vfs_write+0x33/0x150
vfs_write+0xad/0x1a0
SyS_write+0x52/0xc0
do_syscall_64+0x61/0x1a0
entry_SYSCALL64_slow_path+0x25/0x25
Fix this by adding cond_resched every MAX_SCAN_SIZE.
Link: http://lkml.kernel.org/r/1511439788-20099-1-git-send-email-xieyisheng1@huawei.com
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Under some circumstances it's possible to get a divider 0 which crashes
the script.
Traceback (most recent call last):
File "linux/scripts/bloat-o-meter", line 98, in <module>
print_result("Function", "tTdDbBrR", 2)
File "linux/scripts/bloat-o-meter", line 87, in print_result
(otot, ntot, (ntot - otot)*100.0/otot))
ZeroDivisionError: float division by zero
Hide this by checking the divider first.
Link: http://lkml.kernel.org/r/20171123171219.31453-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When running ltp stress test for 7*24 hours, vmscan occasionally emits
the following warning continuously:
mb_cache_scan+0x0/0x3f0 negative objects to delete
nr=-9232265467809300450
...
Tracing shows the freeable(mb_cache_count returns) is -1, which causes
the continuous accumulation and overflow of total_scan.
This patch makes sure that mb_cache_count() cannot return a negative
value, which makes the mbcache shrinker more robust.
Link: http://lkml.kernel.org/r/1511753419-52328-1-git-send-email-jiang.biao2@zte.com.cn
Signed-off-by: Jiang Biao <jiang.biao2@zte.com.cn>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <zhong.weidong@zte.com.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
are illogical"
This reverts commit 0f6d24f87856 ("mm/page-writeback.c: print a warning
if the vm dirtiness settings are illogical") because it causes false
positive warnings during OOM situations as noticed by Tetsuo Handa:
Node 0 active_anon:3525940kB inactive_anon:8372kB active_file:216kB inactive_file:1872kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:2504kB dirty:52kB writeback:0kB shmem:8660kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 636928kB writeback_tmp:0kB unstable:0kB all_unreclaimable? yes
Node 0 DMA free:14848kB min:284kB low:352kB high:420kB active_anon:992kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15904kB mlocked:0kB kernel_stack:0kB pagetables:24kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 2687 3645 3645
Node 0 DMA32 free:53004kB min:49608kB low:62008kB high:74408kB active_anon:2712648kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:3129216kB managed:2773132kB mlocked:0kB kernel_stack:96kB pagetables:5096kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 0 958 958
Node 0 Normal free:17140kB min:17684kB low:22104kB high:26524kB active_anon:812300kB inactive_anon:8372kB active_file:1228kB inactive_file:1868kB unevictable:0kB writepending:52kB present:1048576kB managed:981224kB mlocked:0kB kernel_stack:3520kB pagetables:8552kB bounce:0kB free_pcp:120kB local_pcp:120kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0
[...]
Out of memory: Kill process 8459 (a.out) score 999 or sacrifice child
Killed process 8459 (a.out) total-vm:4180kB, anon-rss:88kB, file-rss:0kB, shmem-rss:0kB
oom_reaper: reaped process 8459 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
vm direct limit must be set greater than background limit.
The problem is that both thresh and bg_thresh will be 0 if
available_memory is less than 4 pages when evaluating
global_dirtyable_memory.
While this might be worked around the whole point of the warning is
dubious at best. We do rely on admins to do sensible things when
changing tunable knobs. Dirty memory writeback knobs are not any
special in that regards so revert the warning rather than adding more
hacks to work this around.
Debugged by Yafang Shao.
Link: http://lkml.kernel.org/r/20171127091939.tahb77nznytcxw55@dhcp22.suse.cz
Fixes: 0f6d24f87856 ("mm/page-writeback.c: print a warning if the vm dirtiness settings are illogical")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Yafang Shao <laoar.shao@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation. The calling
convention is quite subtle there. madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.
It seems this has been broken since introduction. Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.
[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
While the defense-in-depth RLIMIT_STACK limit on setuid processes was
protected against races from other threads calling setrlimit(), I missed
protecting it against races from external processes calling prlimit().
This adds locking around the change and makes sure that rlim_max is set
too.
Link: http://lkml.kernel.org/r/20171127193457.GA11348@beast
Fixes: 64701dee4178e ("exec: Use sane stack rlimit under secureexec")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Reported-by: Brad Spengler <spender@grsecurity.net>
Acked-by: Serge Hallyn <serge@hallyn.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow RDMA to create long standing memory registrations
against filesytem-dax vmas.
Link: http://lkml.kernel.org/r/151068941011.7446.7766030590347262502.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
V4L2 memory registrations are incompatible with filesystem-dax that
needs the ability to revoke dma access to a mapping at will, or
otherwise allow the kernel to wait for completion of DMA. The
filesystem-dax implementation breaks the traditional solution of
truncate of active file backed mappings since there is no page-cache
page we can orphan to sustain ongoing DMA.
If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.
Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow V4L2, Exynos, and other frame vector users to create
long standing / irrevocable memory registrations against filesytem-dax
vmas.
[dan.j.williams@intel.com: add comment for vma_is_fsdax() check in get_vaddr_frames(), per Jan]
Link: http://lkml.kernel.org/r/151197874035.26211.4061781453123083667.stgit@dwillia2-desk3.amr.corp.intel.com
Link: http://lkml.kernel.org/r/151068939985.7446.15684639617389154187.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Patch series "introduce get_user_pages_longterm()", v2.
Here is a new get_user_pages api for cases where a driver intends to
keep an elevated page count indefinitely. This is distinct from usages
like iov_iter_get_pages where the elevated page counts are transient.
The iov_iter_get_pages cases immediately turn around and submit the
pages to a device driver which will put_page when the i/o operation
completes (under kernel control).
In the longterm case userspace is responsible for dropping the page
reference at some undefined point in the future. This is untenable for
filesystem-dax case where the filesystem is in control of the lifetime
of the block / page and needs reasonable limits on how long it can wait
for pages in a mapping to become idle.
Fixing filesystems to actually wait for dax pages to be idle before
blocks from a truncate/hole-punch operation are repurposed is saved for
a later patch series.
Also, allowing longterm registration of dax mappings is a future patch
series that introduces a "map with lease" semantic where the kernel can
revoke a lease and force userspace to drop its page references.
I have also tagged these for -stable to purposely break cases that might
assume that longterm memory registrations for filesystem-dax mappings
were supported by the kernel. The behavior regression this policy
change implies is one of the reasons we maintain the "dax enabled.
Warning: EXPERIMENTAL, use at your own risk" notification when mounting
a filesystem in dax mode.
It is worth noting the device-dax interface does not suffer the same
constraints since it does not support file space management operations
like hole-punch.
This patch (of 4):
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow long standing memory registrations against
filesytem-dax vmas. Device-dax vmas do not have this problem and are
explicitly allowed.
This is temporary until a "memory registration with layout-lease"
mechanism can be implemented for the affected sub-systems (RDMA and
V4L2).
[akpm@linux-foundation.org: use kcalloc()]
Link: http://lkml.kernel.org/r/151068939435.7446.13560129395419350737.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Suggested-by: Christoph Hellwig <hch@lst.de>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Similar to how device-dax enforces that the 'address', 'offset', and
'len' parameters to mmap() be aligned to the device's fundamental
alignment, the same constraints apply to munmap(). Implement ->split()
to fail munmap calls that violate the alignment constraint.
Otherwise, we later fail VM_BUG_ON checks in the unmap_page_range() path
with crash signatures of the form:
vma ffff8800b60c8a88 start 00007f88c0000000 end 00007f88c0e00000
next (null) prev (null) mm ffff8800b61150c0
prot 8000000000000027 anon_vma (null) vm_ops ffffffffa0091240
pgoff 0 file ffff8800b638ef80 private_data (null)
flags: 0x380000fb(read|write|shared|mayread|maywrite|mayexec|mayshare|softdirty|mixedmap|hugepage)
------------[ cut here ]------------
kernel BUG at mm/huge_memory.c:2014!
[..]
RIP: 0010:__split_huge_pud+0x12a/0x180
[..]
Call Trace:
unmap_page_range+0x245/0xa40
? __vma_adjust+0x301/0x990
unmap_vmas+0x4c/0xa0
unmap_region+0xae/0x120
? __vma_rb_erase+0x11a/0x230
do_munmap+0x276/0x410
vm_munmap+0x6a/0xa0
SyS_munmap+0x1d/0x30
Link: http://lkml.kernel.org/r/151130418681.4029.7118245855057952010.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Patch series "device-dax: fix unaligned munmap handling"
When device-dax is operating in huge-page mode we want it to behave like
hugetlbfs and fail attempts to split vmas into unaligned ranges. It
would be messy to teach the munmap path about device-dax alignment
constraints in the same (hstate) way that hugetlbfs communicates this
constraint. Instead, these patches introduce a new ->split() vm
operation.
This patch (of 2):
The device-dax interface has similar constraints as hugetlbfs in that it
requires the munmap path to unmap in huge page aligned units. Rather
than add more custom vma handling code in __split_vma() introduce a new
vm operation to perform this vma specific check.
Link: http://lkml.kernel.org/r/151130418135.4029.6783191281930729710.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When cross-compiling, fadd2line should use the binary tool used for the
target system, rather than that of the host.
Link: http://lkml.kernel.org/r/20171121092911.GA150711@sofia
Signed-off-by: Liu Changcheng <changcheng.liu@intel.com>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: NeilBrown <neilb@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
