Revision 9b4fe5fb0bdd8f31f24cbfe77e38ec8155c250c5 authored by Neil Horman on 12 July 2013, 17:35:33 UTC, committed by David S. Miller on 12 July 2013, 23:28:02 UTC
this bug: https://bugzilla.redhat.com/show_bug.cgi?id=951695 Reported a dma debug backtrace: WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930() Hardware name: To Be Filled By O.E.M. via-rhine 0000:00:12.0: DMA-API: device driver failed to check map error[device address=0x0000000075a837b2] [size=90 bytes] [mapped as single] Modules linked in: ip6_tables gspca_spca561 gspca_main videodev media snd_hda_codec_realtek snd_hda_intel i2c_viapro snd_hda_codec snd_hwdep snd_seq ppdev mperf via_rhine coretemp snd_pcm mii microcode snd_page_alloc snd_timer snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore parport_pc parport shpchp ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper ttm drm pata_via sata_via i2c_core uinput Pid: 295, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.1.fc20.x86_64 #1 Call Trace: <IRQ> [<ffffffff81068dd0>] warn_slowpath_common+0x70/0xa0 [<ffffffff81068e4c>] warn_slowpath_fmt+0x4c/0x50 [<ffffffff8137ec6d>] check_unmap+0x47d/0x930 [<ffffffff810ace9f>] ? local_clock+0x5f/0x70 [<ffffffff8137f17f>] debug_dma_unmap_page+0x5f/0x70 [<ffffffffa0225edc>] ? rhine_ack_events.isra.14+0x3c/0x50 [via_rhine] [<ffffffffa02275f8>] rhine_napipoll+0x1d8/0xd80 [via_rhine] [<ffffffff815d3d51>] ? net_rx_action+0xa1/0x380 [<ffffffff815d3e22>] net_rx_action+0x172/0x380 [<ffffffff8107345f>] __do_softirq+0xff/0x400 [<ffffffff81073925>] irq_exit+0xb5/0xc0 [<ffffffff81724cd6>] do_IRQ+0x56/0xc0 [<ffffffff81719ff2>] common_interrupt+0x72/0x72 <EOI> [<ffffffff8170ff57>] ? __slab_alloc+0x4c2/0x526 [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0 [<ffffffff810d5807>] ? __lock_is_held+0x57/0x80 [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0 [<ffffffff811bf1bf>] kmem_cache_alloc+0x2df/0x360 [<ffffffff811992e0>] mmap_region+0x2b0/0x5a0 [<ffffffff811998e6>] do_mmap_pgoff+0x316/0x3d0 [<ffffffff81183ca0>] vm_mmap_pgoff+0x90/0xc0 [<ffffffff81197d6c>] sys_mmap_pgoff+0x4c/0x190 [<ffffffff81367d7e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8101eb42>] sys_mmap+0x22/0x30 [<ffffffff81722fd9>] system_call_fastpath+0x16/0x1b Usual problem with the usual fix, add the appropriate calls to dma_mapping_error where appropriate Untested, as I don't have hardware, but its pretty straightforward Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: David S. Miller <davem@davemloft.net> CC: Roger Luethi <rl@hellgate.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
1 parent 352900b
stable_kernel_rules.txt
Chinese translated version of Documentation/stable_kernel_rules.txt
If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Chinese maintainer: TripleX Chung <triplex@zh-kernel.org>
---------------------------------------------------------------------
Documentation/stable_kernel_rules.txt 的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。
中文版维护者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
中文版翻译者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
中文版校译者： 李阳 Li Yang <leo@zh-kernel.org>
Kangkai Yin <e12051@motorola.com>
以下为正文
---------------------------------------------------------------------
关于Linux 2.6稳定版发布，所有你想知道的事情。
关于哪些类型的补丁可以被接收进入稳定版代码树，哪些不可以的规则：
- 必须是显而易见的正确，并且经过测试的。
- 连同上下文，不能大于100行。
- 必须只修正一件事情。
- 必须修正了一个给大家带来麻烦的真正的bug（不是“这也许是一个问题...”
那样的东西）。
- 必须修正带来如下后果的问题：编译错误（对被标记为CONFIG_BROKEN的例外），
内核崩溃，挂起，数据损坏，真正的安全问题，或者一些类似“哦，这不
好”的问题。简短的说，就是一些致命的问题。
- 没有“理论上的竞争条件”，除非能给出竞争条件如何被利用的解释。
- 不能存在任何的“琐碎的”修正（拼写修正，去掉多余空格之类的）。
- 必须被相关子系统的维护者接受。
- 必须遵循Documentation/SubmittingPatches里的规则。
向稳定版代码树提交补丁的过程：
- 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。
- 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收
到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。
- 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。
- 安全方面的补丁不要发到这个列表，应该发送到security@kernel.org。
审查周期：
- 当稳定版的维护者决定开始一个审查周期，补丁将被发送到审查委员会，以
及被补丁影响的领域的维护者（除非提交者就是该领域的维护者）并且抄送
到linux-kernel邮件列表。
- 审查委员会有48小时的时间，用来决定给该补丁回复ACK还是NAK。
- 如果委员会中有成员拒绝这个补丁，或者linux-kernel列表上有人反对这个
补丁，并提出维护者和审查委员会之前没有意识到的问题，补丁会从队列中
丢弃。
- 在审查周期结束的时候，那些得到ACK回应的补丁将会被加入到最新的稳定版
发布中，一个新的稳定版发布就此产生。
- 安全性补丁将从内核安全小组那里直接接收到稳定版代码树中，而不是通过
通常的审查周期。请联系内核安全小组以获得关于这个过程的更多细节。
审查委员会：
- 由一些自愿承担这项任务的内核开发者，和几个非志愿的组成。
Computing file changes ...
