- 31 Oct, 2018 40 commits
-
-
Waiman Long authored
Patch series "ipc: IPCMNI limit check for *mni & increase that limit", v9. The sysctl parameters msgmni, shmmni and semmni have an inherent limit of IPC_MNI (32k). However, users may not be aware of that because they can write a value much higher than that without getting any error or notification. Reading the parameters back will show the newly written values which are not real. The real IPCMNI limit is now enforced to make sure that users won't put in an unrealistic value. The first 2 patches enforce the limits. There are also users out there requesting increase in the IPCMNI value. The last 2 patches attempt to do that by using a boot kernel parameter "ipcmni_extend" to increase the IPCMNI limit from 32k to 8M if the users really want the extended value. This patch (of 4): A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is really IPCMNI (32k). This can mislead users as they think they can get a value that is not real. The right limits are now set for msgmni and shmmni so that the users will become aware if they set a value outside of the acceptable range. Link: http://lkml.kernel.org/r/1536352137-12003-2-git-send-email-longman@redhat.comSigned-off-by:
Waiman Long <longman@redhat.com> Acked-by:
Luis R. Rodriguez <mcgrof@kernel.org> Reviewed-by:
Davidlohr Bueso <dave@stgolabs.net> Cc: Kees Cook <keescook@chromium.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox <willy@infradead.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Borislav Petkov authored
If a call to panic() terminates the string with a \n , the result puts the closing brace ']---' on a newline because panic() itself adds \n too. Now, if one goes and removes the newline chars from all panic() invocations - and the stats right now look like this: ~300 calls with a \n ~500 calls without a \n one is destined to a neverending game of whack-a-mole because the usual thing to do is add a newline at the end of a string a function is supposed to print. Therefore, simply zap any \n at the end of the panic string to avoid touching so many places in the kernel. Link: http://lkml.kernel.org/r/20181009205019.2786-1-bp@alien8.deSigned-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Acked-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Borislav Petkov authored
... because panic() itself already does this. Otherwise you have line-broken trailer: [ 1.836965] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: pgd_alloc+0x29e/0x2a0 [ 1.836965] ]--- Link: http://lkml.kernel.org/r/20181008202901.7894-1-bp@alien8.deSigned-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Link: http://lkml.kernel.org/r/20181013114847.GA3160@embeddedor.comSigned-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Weikang Shi authored
Because get_signal_to_deliver() was renamed to get_signal() the comment should be fixed. Link: http://lkml.kernel.org/r/1539179128-45709-1-git-send-email-swkhack@gmail.comSigned-off-by:
Weikang Shi <swkhack@gmail.com> Reported-by:
Christian Brauner <christian@brauner.io> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Anna-Maria Gleixner <anna-maria@linutronix.de> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
Frank Sorenson authored
setattr_copy can't truncate timestamps correctly for msdos/vfat, so truncate and copy them ourselves. Link: http://lkml.kernel.org/r/a2b4701b1125573fafaeaae6802050ca86d6f8cc.1538363961.git.sorenson@redhat.comSigned-off-by:
Frank Sorenson <sorenson@redhat.com> Acked-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Frank Sorenson authored
Convert the inode timestamp updates to use fat_truncate_time. Link: http://lkml.kernel.org/r/2663d3083c4dd62f00b64612c8eaf5542bb05a4c.1538363961.git.sorenson@redhat.comSigned-off-by:
-
Frank Sorenson authored
Add the fat-specific inode_operation ->update_time() and fat_truncate_time() function to truncate the inode timestamps from 1 nanosecond to the appropriate granularity. Link: http://lkml.kernel.org/r/38af1ba3c3cf0d7381ce7b63077ef8af75901532.1538363961.git.sorenson@redhat.comSigned-off-by:
-
Frank Sorenson authored
Patch series "fat: timestamp updates", v5. fat/msdos timestamps are stored on-disk with several different granularities, some of them lower resolution than timespec64_trunc() can provide. In addition, they are only truncated as they are written to disk, so the timestamps in-memory for new or modified files/directories may be different from the same timestamps after a remount, as the now-truncated times are re-read from the on-disk format. These patches allow finer granularity for the timestamps where possible and add fat-specific ->update_time inode operation and fat_truncate_time functions to truncate each timestamp correctly, giving consistent times across remounts. This patch (of 4): Move the calculation of the number of seconds in the timezone offset to a common function. Link: http://lkml.kernel.org/r/3671ff8cff5eeedbb85ebda5e4de0728920db4f6.1538363961.git.sorenson@redhat.comSigned-off-by:
-
Mihir Mehta authored
The file namei.c seems to have been renamed to namei_msdos.c, so I decided to update the comment with the correct name, and expand it a bit to tell the reader what to look for. Link: http://lkml.kernel.org/r/20180928194947.23932-1-mihir@cs.utexas.eduSigned-off-by:
Mihir Mehta <mihir@cs.utexas.edu> Acked-by:
-
Masahiro Yamada authored
cafa0010 ("Raise the minimum required gcc version to 4.6") bumped the minimum GCC version to 4.6 for all architectures. The workaround code in fs/reiserfs/Makefile is obsolete now. Link: http://lkml.kernel.org/r/1535337230-13222-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Jann Horn authored
fill_with_dentries() failed to propagate errors up to reiserfs_for_each_xattr() properly. Plumb them through. Note that reiserfs_for_each_xattr() is only used by reiserfs_delete_xattrs() and reiserfs_chown_xattrs(). The result of reiserfs_delete_xattrs() is discarded anyway, the only difference there is whether a warning is printed to dmesg. The result of reiserfs_chown_xattrs() does matter because it can block chowning of the file to which the xattrs belong; but either way, the resulting state can have misaligned ownership, so my patch doesn't improve things greatly. Credit for making me look at this code goes to Al Viro, who pointed out that the ->actor calling convention is suboptimal and should be changed. Link: http://lkml.kernel.org/r/20180802163335.83312-1-jannh@google.comSigned-off-by:
Jann Horn <jannh@google.com> Reviewed-by:
-
Colin Ian King authored
Currently extent and index i are both being incremented causing an array out of bounds read on extent[i]. Fix this by removing the extraneous increment of extent. Ernesto said: : This is only triggered when deleting a file with a resource fork. I : may be wrong because the documentation isn't clear, but I don't think : you can create those under linux. So I guess nobody was testing them. : : > A disk space leak, perhaps? : : That's what it looks like in general. hfs_free_extents() won't do : anything if the block count doesn't add up, and the error will be : ignored. Now, if the block count randomly does add up, we could see : some corruption. Detected by CoverityScan, CID#711541 ("Out of bounds read") Link: http://lkml.kernel.org/r/20180831140538.31566-1-colin.king@canonical.comSigned-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Ernesto A. Fernndez <ernesto.mnd.fernandez@gmail.com> Cc: David Howells <dhowells@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Signed-off-by:
-
Ernesto A. Fernández authored
The vfs takes care of updating mtime on ftruncate(), but on truncate() it must be done by the module. Link: http://lkml.kernel.org/r/e1611eda2985b672ed2d8677350b4ad8c2d07e8a.1539316825.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Signed-off-by:
-
Ernesto A. Fernández authored
The vfs takes care of updating ctime and mtime on ftruncate(), but on truncate() it must be done by the module. This patch can be tested with xfstests generic/313. Link: http://lkml.kernel.org/r/9beb0913eea37288599e8e1b7cec8768fb52d1b8.1539316825.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
-
Ernesto A. Fernández authored
Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfs is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfs_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/4538ab8c35ea37338490525f0f24cbc37227528c.1539195310.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
-
Ernesto A. Fernández authored
Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfsplus is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfsplus_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/2cd1301404ec7cf1e39c8f11a01a4302f1460ad6.1539195310.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
-
Ernesto A. Fernández authored
Inserting a new record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes or extents. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. There is no need to reserve space before deleting a catalog record, as we do for hfsplus. This difference is because hfs index nodes have fixed length keys. Link: http://lkml.kernel.org/r/ab5fc8a7d5ffccfd5f27b1cf2cb4ceb6c110da74.1536269131.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
-
Ernesto A. Fernández authored
Inserting or deleting a record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes, extents or xattrs. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. The patch can be tested with xfstests generic/027. Link: http://lkml.kernel.org/r/4596eef22fbda137b4ffa0272d92f0da15364421.1536269129.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
-
Ernesto A. Fernández authored
hfs_brec_update_parent() may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. It is not possible for this to happen on a valid hfs filesystem because the index nodes have fixed length keys. For reasons I ignore, the hfs module does have support for a number of hfsplus features. A corrupt btree header may report variable length keys and trigger this BUG, so it's better to fix it. Link: http://lkml.kernel.org/r/cf9b02d57f806217a2b1bf5db8c3e39730d8f603.1535682463.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
-
Ernesto A. Fernández authored
This bug is triggered whenever hfs_brec_update_parent() needs to split the root node. The height of the btree is not increased, which leaves the new node orphaned and its records lost. It is not possible for this to happen on a valid hfs filesystem because the index nodes have fixed length keys. For reasons I ignore, the hfs module does have support for a number of hfsplus features. A corrupt btree header may report variable length keys and trigger this bug, so it's better to fix it. Link: http://lkml.kernel.org/r/9750b1415685c4adca10766895f6d5ef12babdb0.1535682463.git.ernesto.mnd.fernandez@gmail.comSigned-off-by:
-
Ernesto A. Fernández authored
Creating, renaming or deleting a file may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. This bug is triggered by xfstests generic/027, somewhat rarely; here is a more reliable reproducer: truncate -s 50M fs.iso mkfs.hfsplus fs.iso mount fs.iso /mnt i=1000 while [ $i -le 2400 ]; do touch /mnt/$i &>/dev/null ((++i)) done i=2400 while [ $i -ge 1000 ]; do mv /mnt/$i /mnt/$(perl -e "print $i x61") &>/dev/null ((--i)) done The issue is that a newly created bnode is being put twice. Reset new_node to NULL in hfs_brec_update_parent() before reaching goto again. Link: http://lkml.kernel.org/r/5ee1db09b60373a15890f6a7c835d00e76bf601d.1535682461.git.ernesto.mnd.fernandez@gmail.comSigned-off-by: -
Ernesto A. Fernández authored
Creating, renaming or deleting a file may cause catalog corruption and data loss. This bug is randomly triggered by xfstests generic/027, but here is a faster reproducer: truncate -s 50M fs.iso mkfs.hfsplus fs.iso mount fs.iso /mnt i=100 while [ $i -le 150 ]; do touch /mnt/$i &>/dev/null ((++i)) done i=100 while [ $i -le 150 ]; do mv /mnt/$i /mnt/$(perl -e "print $i x82") &>/dev/null ((++i)) done umount /mnt fsck.hfsplus -n fs.iso The bug is triggered whenever hfs_brec_update_parent() needs to split the root node. The height of the btree is not increased, which leaves the new node orphaned and its records lost. Link: http://lkml.kernel.org/r/26d882184fc43043a810114258f45277752186c7.1535682461.git.ernesto.mnd.fernandez@gmail.comSigned-off-by: -
Nikolaus Voss authored
Support referencing the root partition label from GPT as argument to the root= option on the kernel command line in analogy to referencing the partition uuid as root=PARTUUID=<uuid>. Specifying the partition label instead of the uuid is often much easier, e.g. in embedded environments when there is an A/B rootfs partition scheme for interruptible firmware updates (i.e. rootfsA/ rootfsB). The partition label can be queried with the blkid command. Link: http://lkml.kernel.org/r/20180822060904.828E510665E@pc-niv.weinmann.comSigned-off-by:
Nikolaus Voss <nikolaus.voss@loewensteinmedical.de> Reviewed-by:
-
Christophe Leroy authored
This warning was there to avoid the use of 0bxxx values as they are not supported by gcc prior to v4.3 Since cafa0010 ("Raise the minimum required gcc version to 4.6"), it's not an issue anymore and using such values can increase readability of code. Joe said: : Seems sensible as the other compilers also support binary literals from : relatively old versions. : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf : https://software.intel.com/en-us/articles/c14-features-supported-by-intel-c-compiler Link: http://lkml.kernel.org/r/392eeae782302ee8812a3c932a602035deed1609.1535351453.git.christophe.leroy@c-s.frSigned-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Link: http://lkml.kernel.org/r/20181013115048.GA3262@embeddedor.comSigned-off-by:
-
Alexey Dobriyan authored
Implicit casts to the same type are done by the language if necessary. Link: http://lkml.kernel.org/r/20181014223934.GA18107@avx2Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by:
-
Wei Yang authored
The function name in the comment is not correct. Link: http://lkml.kernel.org/r/20181010021344.60433-1-richard.weiyang@gmail.comSigned-off-by:
Wei Yang <richard.weiyang@gmail.com> Signed-off-by:
-
zhong jiang authored
mempool_destroy(NULL) and kmem_cache_destroy(NULL) are legal Link: http://lkml.kernel.org/r/1533054107-35657-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
zhong jiang <zhongjiang@huawei.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Corentin Labbe authored
This patch remove all following fall through warnings by adding /* fall through */ markers. Note that we cannot add "__attribute__ ((fallthrough));" due to it is GCC7 only arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:384:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:391:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:393:16: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:430:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:556:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:595:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:602:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:627:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:646:25: warning: this statement may fall through [-Wimplicit-fallthrough=] arch/arm/boot/compressed/../../../../lib/zlib_inflate/inflate.c:696:25: warning: this statement may fall through [-Wimplicit-fallthrough=] It is easy to see that thoses fall through are needed since in each case state->mode are set to the case value just below. Link: http://lkml.kernel.org/r/1536215920-19955-1-git-send-email-clabbe@baylibre.comSigned-off-by:
Corentin Labbe <clabbe@baylibre.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Eric Biggers authored
This simplifies the code. No change in behavior. Link: http://lkml.kernel.org/r/20180830194727.191555-1-ebiggers@kernel.orgSigned-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
-
Eric Biggers authored
This simplifies the code. No change in behavior. Link: http://lkml.kernel.org/r/20180830194814.192880-1-ebiggers@kernel.orgSigned-off-by:
-
Eric Biggers authored
This simplifies the code. No change in behavior. Link: http://lkml.kernel.org/r/20180830194436.188867-1-ebiggers@kernel.orgSigned-off-by:
-
Rasmus Villemoes authored
len is guaranteed to lie in [1, PAGE_SIZE]. If scnprintf is called with a buffer size of 1, it is guaranteed to return 0. So in the extremely unlikely case of having just one byte remaining in the page, let's just call scnprintf anyway. The only difference is that this will write a '\0' to that final byte in the page, but that's an improvement: We now guarantee that after the call, buf is a properly terminated C string of length exactly the return value. Link: http://lkml.kernel.org/r/20180818131623.8755-8-linux@rasmusvillemoes.dkSigned-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Yury Norov <ynorov@caviumnetworks.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Rasmus Villemoes authored
For various alignments of buf, the current expression computes 4096 ok 4095 ok 8190 8189 ... 4097 i.e., if the caller has already written two bytes into the page buffer, len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next boundary. So if the printed version of the bitmap is huge, scnprintf() ends up writing beyond the page boundary. I don't think any current callers actually write anything before bitmap_print_to_pagebuf, but the API seems to be designed to allow it. [akpm@linux-foundation.org: use offset_in_page(), per Andy] [akpm@linux-foundation.org: include mm.h for offset_in_page()] Link: http://lkml.kernel.org/r/20180818131623.8755-7-linux@rasmusvillemoes.dkSigned-off-by:
-
Rasmus Villemoes authored
It's not clear what's so horrible about emitting a function call to handle a run-time sized bitmap. Moreover, gcc also emits a function call for a compile-time-constant-but-huge nbits, so the comment isn't even accurate. Link: http://lkml.kernel.org/r/20180818131623.8755-6-linux@rasmusvillemoes.dkSigned-off-by:
-
Rasmus Villemoes authored
Most other bitmap API, including the OOL version __bitmap_shift_right, take unsigned nbits. This was accidentally left out from 2fbad299. Link: http://lkml.kernel.org/r/20180818131623.8755-5-linux@rasmusvillemoes.dk Fixes: 2fbad299 ("lib: bitmap: change bitmap_shift_right to take unsigned parameters") Signed-off-by:
Yury Norov <ynorov@caviumnetworks.com> Reviewed-by:
-
Rasmus Villemoes authored
In the _zero, _fill and _copy functions, the small_const_nbits branch is redundant. If nbits is small and const, gcc knows full well that BITS_TO_LONGS(nbits) is 1, so len is also a compile-time constant (sizeof(long)), and calling memset or memcpy with a length argument of sizeof(long) makes gcc generate the expected code anyway: #include <string.h> void a(unsigned long *x) { memset(x, 0, 8); } void b(unsigned long *x) { memset(x, 0xff, 8); } void c(unsigned long *x, const unsigned long *y) { memcpy(x, y, 8); } turns into 0000000000000000 <a>: 0: 48 c7 07 00 00 00 00 movq $0x0,(%rdi) 7: c3 retq 8: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) f: 00 0000000000000010 <b>: 10: 48 c7 07 ff ff ff ff movq $0xffffffffffffffff,(%rdi) 17: c3 retq 18: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 1f: 00 0000000000000020 <c>: 20: 48 8b 06 mov (%rsi),%rax 23: 48 89 07 mov %rax,(%rdi) 26: c3 retq Link: http://lkml.kernel.org/r/20180818131623.8755-4-linux@rasmusvillemoes.dkSigned-off-by: -
Rasmus Villemoes authored
The static inlines in bitmap.h do not handle a compile-time constant nbits==0 correctly (they dereference the passed src or dst pointers, despite only 0 words being valid to access). I had the 0-day buildbot chew on a patch [1] that would cause build failures for such cases without complaining, suggesting that we don't have any such users currently, at least for the 70 .config/arch combinations that was built. Should any turn up, make sure they use the out-of-line versions, which do handle nbits==0 correctly. This is of course not the most efficient, but it's much less churn than teaching all the static inlines an "if (zero_const_nbits())", and since we don't have any current instances, this doesn't affect existing code at all. [1] lkml.kernel.org/r/20180815085539.27485-1-linux@rasmusvillemoes.dk Link: http://lkml.kernel.org/r/20180818131623.8755-3-linux@rasmusvillemoes.dkSigned-off-by:
-
Rasmus Villemoes authored
This promise is violated in a number of places, e.g. already in the second function below this paragraph. Since I don't think anybody relies on this being true, and since actually honouring it would hurt performance and code size in various places, just remove the paragraph. Link: http://lkml.kernel.org/r/20180818131623.8755-2-linux@rasmusvillemoes.dkSigned-off-by:
-
