Revision 732256b9335f8456623bb772d86c2a24e3cafca2 authored by Erik Hugne on 07 January 2014, 20:51:36 UTC, committed by David S. Miller on 07 January 2014, 21:15:24 UTC
When we pull a received packet from a link's 'deferred packets' queue
for processing, its 'next' pointer is not cleared, and still refers to
the next packet in that queue, if any. This is incorrect, but caused
no harm before commit 40ba3cdf542a469aaa9083fa041656e59b109b90 ("tipc:
message reassembly using fragment chain") was introduced. After that
commit, it may sometimes lead to the following oops:

general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: tipc
CPU: 4 PID: 0 Comm: swapper/4 Tainted: G        W 3.13.0-rc2+ #6
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
task: ffff880017af4880 ti: ffff880017aee000 task.ti: ffff880017aee000
RIP: 0010:[<ffffffff81710694>]  [<ffffffff81710694>] skb_try_coalesce+0x44/0x3d0
RSP: 0018:ffff880016603a78  EFLAGS: 00010212
RAX: 6b6b6b6bd6d6d6d6 RBX: ffff880013106ac0 RCX: ffff880016603ad0
RDX: ffff880016603ad7 RSI: ffff88001223ed00 RDI: ffff880013106ac0
RBP: ffff880016603ab8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88001223ed00
R13: ffff880016603ad0 R14: 000000000000058c R15: ffff880012297650
FS:  0000000000000000(0000) GS:ffff880016600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000805b000 CR3: 0000000011f5d000 CR4: 00000000000006e0
Stack:
 ffff880016603a88 ffffffff810a38ed ffff880016603aa8 ffff88001223ed00
 0000000000000001 ffff880012297648 ffff880016603b68 ffff880012297650
 ffff880016603b08 ffffffffa0006c51 ffff880016603b08 00ffffffa00005fc
Call Trace:
 <IRQ>
 [<ffffffff810a38ed>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffffa0006c51>] tipc_link_recv_fragment+0xd1/0x1b0 [tipc]
 [<ffffffffa0007214>] tipc_recv_msg+0x4e4/0x920 [tipc]
 [<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
 [<ffffffffa000177c>] tipc_l2_rcv_msg+0xcc/0x250 [tipc]
 [<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
 [<ffffffff8171e65b>] __netif_receive_skb_core+0x80b/0xd00
 [<ffffffff8171df94>] ? __netif_receive_skb_core+0x144/0xd00
 [<ffffffff8171eb76>] __netif_receive_skb+0x26/0x70
 [<ffffffff8171ed6d>] netif_receive_skb+0x2d/0x200
 [<ffffffff8171fe70>] napi_gro_receive+0xb0/0x130
 [<ffffffff815647c2>] e1000_clean_rx_irq+0x2c2/0x530
 [<ffffffff81565986>] e1000_clean+0x266/0x9c0
 [<ffffffff81985f7b>] ? notifier_call_chain+0x2b/0x160
 [<ffffffff8171f971>] net_rx_action+0x141/0x310
 [<ffffffff81051c1b>] __do_softirq+0xeb/0x480
 [<ffffffff819817bb>] ? _raw_spin_unlock+0x2b/0x40
 [<ffffffff810b8c42>] ? handle_fasteoi_irq+0x72/0x100
 [<ffffffff81052346>] irq_exit+0x96/0xc0
 [<ffffffff8198cbc3>] do_IRQ+0x63/0xe0
 [<ffffffff81981def>] common_interrupt+0x6f/0x6f
 <EOI>

This happens when the last fragment of a message has passed through the
the receiving link's 'deferred packets' queue, and at least one other
packet was added to that queue while it was there. After the fragment
chain with the complete message has been successfully delivered to the
receiving socket, it is released. Since 'next' pointer of the last
fragment in the released chain now is non-NULL, we get the crash shown
above.

We fix this by clearing the 'next' pointer of all received packets,
including those being pulled from the 'deferred' queue, before they
undergo any further processing.

Fixes: 40ba3cdf542a4 ("tipc: message reassembly using fragment chain")
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Reported-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1 parent 657e5d1
Raw File
Kconfig
#
# Configuration for initramfs
#

config INITRAMFS_SOURCE
	string "Initramfs source file(s)"
	default ""
	help
	  This can be either a single cpio archive with a .cpio suffix or a
	  space-separated list of directories and files for building the
	  initramfs image.  A cpio archive should contain a filesystem archive
	  to be used as an initramfs image.  Directories should contain a
	  filesystem layout to be included in the initramfs image.  Files
	  should contain entries according to the format described by the
	  "usr/gen_init_cpio" program in the kernel tree.

	  When multiple directories and files are specified then the
	  initramfs image will be the aggregate of all of them.

	  See <file:Documentation/early-userspace/README> for more details.

	  If you are not sure, leave it blank.

config INITRAMFS_ROOT_UID
	int "User ID to map to 0 (user root)"
	depends on INITRAMFS_SOURCE!=""
	default "0"
	help
	  This setting is only meaningful if the INITRAMFS_SOURCE is
	  contains a directory.  Setting this user ID (UID) to something
	  other than "0" will cause all files owned by that UID to be
	  owned by user root in the initial ramdisk image.

	  If you are not sure, leave it set to "0".

config INITRAMFS_ROOT_GID
	int "Group ID to map to 0 (group root)"
	depends on INITRAMFS_SOURCE!=""
	default "0"
	help
	  This setting is only meaningful if the INITRAMFS_SOURCE is
	  contains a directory.  Setting this group ID (GID) to something
	  other than "0" will cause all files owned by that GID to be
	  owned by group root in the initial ramdisk image.

	  If you are not sure, leave it set to "0".

config RD_GZIP
	bool "Support initial ramdisks compressed using gzip" if EXPERT
	default y
	depends on BLK_DEV_INITRD
	select DECOMPRESS_GZIP
	help
	  Support loading of a gzip encoded initial ramdisk or cpio buffer.
	  If unsure, say Y.

config RD_BZIP2
	bool "Support initial ramdisks compressed using bzip2" if EXPERT
	default !EXPERT
	depends on BLK_DEV_INITRD
	select DECOMPRESS_BZIP2
	help
	  Support loading of a bzip2 encoded initial ramdisk or cpio buffer
	  If unsure, say N.

config RD_LZMA
	bool "Support initial ramdisks compressed using LZMA" if EXPERT
	default !EXPERT
	depends on BLK_DEV_INITRD
	select DECOMPRESS_LZMA
	help
	  Support loading of a LZMA encoded initial ramdisk or cpio buffer
	  If unsure, say N.

config RD_XZ
	bool "Support initial ramdisks compressed using XZ" if EXPERT
	default !EXPERT
	depends on BLK_DEV_INITRD
	select DECOMPRESS_XZ
	help
	  Support loading of a XZ encoded initial ramdisk or cpio buffer.
	  If unsure, say N.

config RD_LZO
	bool "Support initial ramdisks compressed using LZO" if EXPERT
	default !EXPERT
	depends on BLK_DEV_INITRD
	select DECOMPRESS_LZO
	help
	  Support loading of a LZO encoded initial ramdisk or cpio buffer
	  If unsure, say N.

config RD_LZ4
	bool "Support initial ramdisks compressed using LZ4" if EXPERT
	default !EXPERT
	depends on BLK_DEV_INITRD
	select DECOMPRESS_LZ4
	help
	  Support loading of a LZ4 encoded initial ramdisk or cpio buffer
	  If unsure, say N.

choice
	prompt "Built-in initramfs compression mode" if INITRAMFS_SOURCE!=""
	help
	  This option decides by which algorithm the builtin initramfs
	  will be compressed.  Several compression algorithms are
	  available, which differ in efficiency, compression and
	  decompression speed.  Compression speed is only relevant
	  when building a kernel.  Decompression speed is relevant at
	  each boot.

	  If you have any problems with bzip2 or LZMA compressed
	  initramfs, mail me (Alain Knaff) <alain@knaff.lu>.

	  High compression options are mostly useful for users who are
	  low on RAM, since it reduces the memory consumption during
	  boot.

	  If in doubt, select 'gzip'

config INITRAMFS_COMPRESSION_NONE
	bool "None"
	help
	  Do not compress the built-in initramfs at all. This may
	  sound wasteful in space, but, you should be aware that the
	  built-in initramfs will be compressed at a later stage
	  anyways along with the rest of the kernel, on those
	  architectures that support this.
	  However, not compressing the initramfs may lead to slightly
	  higher memory consumption during a short time at boot, while
	  both the cpio image and the unpacked filesystem image will
	  be present in memory simultaneously

config INITRAMFS_COMPRESSION_GZIP
	bool "Gzip"
	depends on RD_GZIP
	help
	  The old and tried gzip compression. It provides a good balance
	  between compression ratio and decompression speed.

config INITRAMFS_COMPRESSION_BZIP2
	bool "Bzip2"
	depends on RD_BZIP2
	help
	  Its compression ratio and speed is intermediate.
	  Decompression speed is slowest among the choices.  The initramfs
	  size is about 10% smaller with bzip2, in comparison to gzip.
	  Bzip2 uses a large amount of memory. For modern kernels you
	  will need at least 8MB RAM or more for booting.

config INITRAMFS_COMPRESSION_LZMA
	bool "LZMA"
	depends on RD_LZMA
	help
	  This algorithm's compression ratio is best.
	  Decompression speed is between the other choices.
	  Compression is slowest. The initramfs size is about 33%
	  smaller with LZMA in comparison to gzip.

config INITRAMFS_COMPRESSION_XZ
	bool "XZ"
	depends on RD_XZ
	help
	  XZ uses the LZMA2 algorithm. The initramfs size is about 30%
	  smaller with XZ in comparison to gzip. Decompression speed
	  is better than that of bzip2 but worse than gzip and LZO.
	  Compression is slow.

config INITRAMFS_COMPRESSION_LZO
	bool "LZO"
	depends on RD_LZO
	help
	  Its compression ratio is the poorest among the choices. The kernel
	  size is about 10% bigger than gzip; however its speed
	  (both compression and decompression) is the fastest.

endchoice
back to top