dm-default-key is needed for metadata encryption
(https://source.android.com/security/encryption/metadata).
The new version of dm-default-key is vendor-independent and can be used
both with and without inline encryption hardware.
Bug: 137270441
Bug: 147814592
Change-Id: I92ce45c4b1543ff8bc5cdb5ebe4ddcdb740c2dc7
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add a device-mapper target "dm-default-key" which assigns an encryption
key to bios that aren't for the contents of an encrypted file.
This ensures that all blocks on-disk will be encrypted with some key,
without the performance hit of file contents being encrypted twice when
fscrypt (File-Based Encryption) is used.
It is only appropriate to use dm-default-key when key configuration is
tightly controlled, like it is in Android, such that all fscrypt keys
are at least as hard to compromise as the default key.
Compared to the original version of dm-default-key, this has been
modified to use the new vendor-independent inline encryption framework
(which works even when no inline encryption hardware is present), the
table syntax has been changed to match dm-crypt, and support for
specifying Adiantum encryption has been added. These changes also mean
that dm-default-key now always explicitly specifies the DUN (the IV).
Also, to handle f2fs moving blocks of encrypted files around without the
key, and to handle ext4 and f2fs filesystems mounted without
'-o inlinecrypt', the mapping logic is no longer "set a key on the bio
if it doesn't have one already", but rather "set a key on the bio unless
the bio has the bi_skip_dm_default_key flag set". Filesystems set this
flag on *all* bios for encrypted file contents, regardless of whether
they are encrypting/decrypting the file using inline encryption or the
traditional filesystem-layer encryption, or moving the raw data.
For the bi_skip_dm_default_key flag, a new field in struct bio is used
rather than a bit in bi_opf so that fscrypt_set_bio_crypt_ctx() can set
the flag, minimizing the changes needed to filesystems. (bi_opf is
usually overwritten after fscrypt_set_bio_crypt_ctx() is called.)
Bug: 137270441
Bug: 147814592
Change-Id: I69c9cd1e968ccf990e4ad96e5115b662237f5095
Signed-off-by: Eric Biggers <ebiggers@google.com>
dm-linear obviously can pass through inline crypto support.
In addition, we need dm-bow to pass through inline crypto support, as
the userdata partition in Android may be located on top of dm-bow.
Bug: 137270441
Change-Id: Ib9b0f67b77391fa450394568ceed441c1508de6e
Signed-off-by: Eric Biggers <ebiggers@google.com>
Update the device-mapper core to support exposing the inline crypto
support of the underlying device(s) through the device-mapper device.
This works by creating a "passthrough keyslot manager" for the dm
device, which declares support for the set of (crypto_mode,
data_unit_size) combos which all the underlying devices support. When a
supported combo is used, the bio cloning code handles cloning the crypto
context to the bios for all the underlying devices. When an unsupported
combo is used, the blk-crypto fallback is used as usual.
Crypto support on each underlying device is ignored unless the
corresponding dm target opts into exposing it. This is needed because
for inline crypto to semantically operate on the original bio, the data
must not be transformed by the dm target. Thus, targets like dm-linear
can expose crypto support of the underlying device, but targets like
dm-crypt can't. (dm-crypt could use inline crypto itself, though.)
When a key is evicted from the dm device, it is evicted from all
underlying devices.
Bug: 137270441
Bug: 147814592
Change-Id: If28b574f2e28268db5eb9f325d4cf8f96cb63e3f
Signed-off-by: Eric Biggers <ebiggers@google.com>
The regular keyslot manager is designed for devices that have a small
number of keyslots that need to be programmed with keys ahead of time,
and bios that are sent to the device need to be tagged with a keyslot
index.
Some inline encryption hardware may not have any limitations on the
number of keyslot, and may instead allow each bio to be tagged with
a raw key, data unit number, etc. rather than a pre-programmed keyslot's
index. These devices don't need any sort of keyslot management, and it's
better for these devices not to have to allocate a regular keyslot
manager with some fixed number of keyslots. These devices can instead
set up a passthrough keyslot manager in their request queue, which
require less resources than regular keyslot managers, as they simply
do no-ops when trying to program keys into slots.
Separately, the device mapper may map over devices that have inline
encryption hardware, and it wants to pass the key along to the
underlying hardware. While the DM layer can expose inline encryption
capabilities by setting up a regular keyslot manager with some fixed
number of keyslots in the dm device's request queue, this only wastes
memory since the keys programmed into the dm device's request queue
will never be used. Instead, it's better to set up a passthrough
keyslot manager for dm devices.
Bug: 137270441
Bug: 147814592
Change-Id: I6d91e83e86a73b0d6066873c8a9117cf2c089234
Signed-off-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
ext4 and f2fs have traditionally not supported direct I/O on encrypted
files, since it's difficult to implement with the traditional
filesystem-layer encryption. But when inline encryption is used
instead, it's straightforward to support direct I/O, as long as the I/O
is fully filesystem-block-aligned. Add support for it by:
- Making the two generic direct I/O implementations in the kernel,
__blockdev_direct_IO() and iomap_dio_rw(), set the encryption context
on bios for inline-encrypted files. __blockdev_direct_IO() is used by
f2fs, and was used by ext4 in kernel v5.4 and earlier. iomap_dio_rw()
is used by ext4 in kernel v5.5 and later.
- Making ext4 and f2fs allow direct I/O to encrypted files (rather the
current behavior of falling back to buffered I/O) when the file is
using inline encryption and the I/O is fully filesystem-block-aligned.
Bug: 137270441
Change-Id: I4c8f7497eb8f829d03611d24281113d68c21d4d1
Signed-off-by: Eric Biggers <ebiggers@google.com>
On Snapdragon SoCs, the Linux kernel isn't permitted to directly access
the standard UFS crypto configuration registers. Instead, programming
and evicting keys must be done through vendor-specific SMC calls.
To support this hardware, add a ->program_key() method to
'struct ufs_hba_variant_ops'. This allows overriding the UFS standard
key programming procedure.
Link: https://lore.kernel.org/r/20200110061634.46742-5-ebiggers@kernel.org
Bug: 137270441
Bug: 147259927
Change-Id: Ia561d5a51421baaf78de52a1eaec496093a0d0ad
Signed-off-by: Eric Biggers <ebiggers@google.com>
Export the blk-crypto symbols needed for modules to use inline crypto.
These would have already been exported, except that so far they've only
been used by fs/crypto/, which is no longer modular.
Bug: 137270441
Bug: 147814592
Change-Id: I64bf98aecabe891c188b30dd50124aacb1e008ca
Signed-off-by: Eric Biggers <ebiggers@google.com>
While we're waiting for v7 of the inline crypto patchset, fix some bugs
that made it into the v6 patchset, including one that caused bios with
an encryption context to never be merged, and one that could cause
non-contiguous pages to incorrectly added to a bio.
Bug: 137270441
Change-Id: I3911fcd6c76b5c9063b86d6af6267ad990a46718
Signed-off-by: Eric Biggers <ebiggers@google.com>
If a block device supports rw_page operation, it doesn't submit bios so
the annotation in submit_bio() for refault stall doesn't work. It
happens with zram in android, especially swap read path which could
consume CPU cycle for decompress. It is also a problem for zswap which
uses frontswap.
Annotate swap_readpage() to account the synchronous IO overhead to
prevent underreport memory pressure.
[akpm@linux-foundation.org: add comment, per Johannes]
Link: http://lkml.kernel.org/r/20191010152134.38545-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@google.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 937790699b)
Bug: 142418748
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ibb3ca48ad331af38a99ea428dcfbd78a26758739
Upstream commit 0f181f9fbe ("mm/slub.c: init_on_free=1 should wipe freelist
ptr for bulk allocations").
slab_alloc_node() already zeroed out the freelist pointer if
init_on_free was on. Thibaut Sautereau noticed that the same needs to
be done for kmem_cache_alloc_bulk(), which performs the allocations
separately.
kmem_cache_alloc_bulk() is currently used in two places in the kernel,
so this change is unlikely to have a major performance impact.
SLAB doesn't require a similar change, as auto-initialization makes the
allocator store the freelist pointers off-slab.
Link: http://lkml.kernel.org/r/20191007091605.30530-1-glider@google.com
Fixes: 6471384af2 ("mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options")
Signed-off-by: Alexander Potapenko <glider@google.com>
Reported-by: Thibaut Sautereau <thibaut@sautereau.fr>
Reported-by: Kees Cook <keescook@chromium.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Laura Abbott <labbott@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 138435492
Test: Boot an ARM64 mobile device with and without init_on_alloc=1
Change-Id: Iec7e3ab5c536f62183ad5a1e6003a56e49012286
Signed-off-by: Alexander Potapenko <glider@google.com>
Export the symbols cma_get_name, cma_alloc, cma_release
and cma_for_each_area.
These are required to modularize the ion driver.
Test: build
Bug: 147914088
Change-Id: I873fd346265be1395d2ba738aca6b9dee03700e2
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Test: build, boot and video playback works on cuttlefish
Bug: 147914088
Change-Id: I6143f0def4047a84eb0f7a4c33df1c1cf3b6ffe2
Signed-off-by: Hridya Valsaraju <hridya@google.com>
The symbol is required by the ion driver when modularized.
Test: build, boot
Bug: 147914088
Change-Id: I667866e809cb00c5ad0f39ed82b20f5fc3397a0f
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Unfork Android.
This reverts commit 8e5e42d5ae.
Perf_event_paranoid=3 is no longer needed on Android. Access control
of perf events is now done by selinux. See:
https://patchwork.kernel.org/patch/11185793/
Bug: 120445712
Bug: 137092007
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: Iba493424174b30baff460caaa25a54a472c87bd4
Map the permission gating RTM_GETLINK messages to a new permission so
that it can be distinguished from the other netlink route permissions
in selinux policy.
This is a temporary Android-only patch that will be deprecated in
newer kernels once the long-term solution lands as discusssed on the
mailing list [1]. The maintainer's recommended solution is more
general, much more complex, and likely not suitable for backporting.
This patch provides the minimal change needed for Android including
the userspace settable trigger which ensures that the permission
change is only applied to the newest version of Android which
contains the changes needed for userpace compatibility.
[1]: https://lore.kernel.org/selinux/20200116142653.61738-1-jeffv@google.com/
Bug: 141455849
Bug: 148218425
Test: CtsSelinuxTargetSdkCurrentTestCases
Test: atest bionic-unit-tests-static
Test: atest NetworkInterfaceTest
Test: Connect to Wi-Fi network
Test: Set up hotspot
Test: Cast from device
Test: Pair Bluetooth device
Test: Call getifaddrs() directly from within an app.
Test: Call NetworkInterface#getNetworkInterfaces() from within an app.
Change-Id: I7b44ce60ad98f858c412722d41b9842f8577151f
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
This patch allows genfscon per-file labeling for binderfs.
This is required to have separate permissions to allow
access to binder, hwbinder and vndbinder devices which are
relocating to binderfs.
Acked-by: Jeff Vander Stoep <jeffv@google.com>
Acked-by: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Bug: 136497735
(cherry picked from commit 7a4b519474
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
master)
Link: https://lore.kernel.org/patchwork/patch/1175776/
Change-Id: I105cc54b30ddd4120dc23a363bddc2f9d00e4dc4
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 2 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 1 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some sub-type change:
[C]'function void blk_queue_logical_block_size(request_queue*, unsigned short int)' at blk-settings.c:382:1 has some sub-type changes:
parameter 2 of type 'unsigned short int' changed:
type name changed from 'unsigned short int' to 'unsigned int'
type size changed from 16 to 32 (in bits)
'struct queue_limits at blkdev.h:365:1' changed:
type size hasn't changed
there are data member changes:
'unsigned int queue_limits::alignment_offset' offset changed from 384 to 416 (in bits) (by +32 bits)
'unsigned int queue_limits::io_min' offset changed from 416 to 448 (in bits) (by +32 bits)
'unsigned int queue_limits::io_opt' offset changed from 448 to 480 (in bits) (by +32 bits)
'unsigned int queue_limits::max_discard_sectors' offset changed from 480 to 512 (in bits) (by +32 bits)
'unsigned int queue_limits::max_hw_discard_sectors' offset changed from 512 to 544 (in bits) (by +32 bits)
'unsigned int queue_limits::max_write_same_sectors' offset changed from 544 to 576 (in bits) (by +32 bits)
'unsigned int queue_limits::max_write_zeroes_sectors' offset changed from 576 to 608 (in bits) (by +32 bits)
'unsigned int queue_limits::discard_granularity' offset changed from 608 to 640 (in bits) (by +32 bits)
'unsigned int queue_limits::discard_alignment' offset changed from 640 to 672 (in bits) (by +32 bits)
type 'unsigned short int' of 'queue_limits::logical_block_size' changed:
type name changed from 'unsigned short int' to 'unsigned int'
type size changed from 16 to 32 (in bits)
, offset changed from 672 to 384 (in bits) (by -288 bits), size changed from 16 to 32 (in bits) (by +16 bits)
'unsigned short int queue_limits::max_segments' offset changed from 688 to 704 (in bits) (by +16 bits)
'unsigned short int queue_limits::max_integrity_segments' offset changed from 704 to 720 (in bits) (by +16 bits)
'unsigned short int queue_limits::max_discard_segments' offset changed from 720 to 736 (in bits) (by +16 bits)
'unsigned char queue_limits::misaligned' offset changed from 736 to 752 (in bits) (by +16 bits)
'unsigned char queue_limits::discard_misaligned' offset changed from 744 to 760 (in bits) (by +16 bits)
'unsigned char queue_limits::cluster' offset changed from 752 to 768 (in bits) (by +16 bits)
'unsigned char queue_limits::raid_partial_stripes_expensive' offset changed from 760 to 776 (in bits) (by +16 bits)
'blk_zoned_model queue_limits::zoned' offset changed from 768 to 800 (in bits) (by +32 bits)
37 impacted interfaces
'struct request_queue at blkdev.h:434:1' changed:
type size hasn't changed
there are data member changes:
type 'struct queue_limits' of 'request_queue::limits' changed as reported earlier
37 impacted interfaces
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5d948f629b31c74f5d3c3d5a65a92b59b7798390
commit 07d3698578 upstream.
Since there are some DIE which has only ranges instead of the
combination of entrypc/highpc, address verification must use
dwarf_haspc() instead of dwarf_entrypc/dwarf_highpc.
Also, the ranges only DIE will have a partial code in different section
(e.g. unlikely code will be in text.unlikely as "FUNC.cold" symbol). In
that case, we can not use dwarf_entrypc() or die_entrypc(), because the
offset from original DIE can be a minus value.
Instead, this simply gets the symbol and offset from symtab.
Without this patch;
# perf probe -D clear_tasks_mm_cpumask:1
Failed to get entry address of clear_tasks_mm_cpumask
Error: Failed to add events.
And with this patch:
# perf probe -D clear_tasks_mm_cpumask:1
p:probe/clear_tasks_mm_cpumask clear_tasks_mm_cpumask+0
p:probe/clear_tasks_mm_cpumask_1 clear_tasks_mm_cpumask+5
p:probe/clear_tasks_mm_cpumask_2 clear_tasks_mm_cpumask+8
p:probe/clear_tasks_mm_cpumask_3 clear_tasks_mm_cpumask+16
p:probe/clear_tasks_mm_cpumask_4 clear_tasks_mm_cpumask+82
Committer testing:
I managed to reproduce the above:
[root@quaco ~]# perf probe -D clear_tasks_mm_cpumask:1
p:probe/clear_tasks_mm_cpumask _text+919968
p:probe/clear_tasks_mm_cpumask_1 _text+919973
p:probe/clear_tasks_mm_cpumask_2 _text+919976
[root@quaco ~]#
But then when trying to actually put the probe in place, it fails if I
use :0 as the offset:
[root@quaco ~]# perf probe -L clear_tasks_mm_cpumask | head -5
<clear_tasks_mm_cpumask@/usr/src/debug/kernel-5.2.fc30/linux-5.2.18-200.fc30.x86_64/kernel/cpu.c:0>
0 void clear_tasks_mm_cpumask(int cpu)
1 {
2 struct task_struct *p;
[root@quaco ~]# perf probe clear_tasks_mm_cpumask:0
Probe point 'clear_tasks_mm_cpumask' not found.
Error: Failed to add events.
[root@quaco
The next patch is needed to fix this case.
Fixes: 576b523721 ("perf probe: Fix probing symbols with optimization suffix")
Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157199318513.8075.10463906803299647907.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 394440d469 upstream.
Commit 60e4cf67a5 (reiserfs: fix extended attributes on the root
directory) introduced a regression open_xa_root started returning
-EOPNOTSUPP but it was not handled properly in reiserfs_for_each_xattr.
When the reiserfs module is built without CONFIG_REISERFS_FS_XATTR,
deleting an inode would result in a warning and chowning an inode
would also result in a warning and then fail to complete.
With CONFIG_REISERFS_FS_XATTR enabled, the xattr root would always be
present for read-write operations.
This commit handles -EOPNOSUPP in the same way -ENODATA is handled.
Fixes: 60e4cf67a5 ("reiserfs: fix extended attributes on the root directory")
CC: stable@vger.kernel.org # Commit 60e4cf67a5 was picked up by stable
Link: https://lore.kernel.org/r/20200115180059.6935-1-jeffm@suse.com
Reported-by: Michael Brunnbauer <brunni@netestate.de>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 15516bf9ab upstream.
If the BAR initialization failed it may leave the vmm structure in an
unitialized state, leading to a null-pointer-dereference when the vmm is
dereferenced during teardown.
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sushma Kalakota <sushmax.kalakota@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 14f89e0881 upstream.
Due to the use of sizeof(), command size set for the spi transfer
was wrong. Driver was sending and receiving always 1 byte less
and especially on write, it was hanging.
echo -n -e "\\x1\\x2\\x3\\x4" > /dev/mtd1
And read part too now works as expected.
hexdump -C -n16 /dev/mtd1
00000000 01 02 03 04 ab f3 ad c2 ab e3 f4 36 dd 38 04 15
00000010
Fixes: 4379075a87 ("mtd: mchp23k256: Add support for mchp23lcv1024")
Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 54fb3fe0f2 upstream.
This reverts commit 193d00a2b3.
Commit 951d48855d ("of: Make of_dma_get_range() work on bus nodes")
reworked the logic such that of_dma_get_range() works correctly
starting from a bus node containing "dma-ranges".
Since on Juno we don't have a SoC level bus node and "dma-ranges" is
present only in the root node, we get the following error:
OF: translation of DMA address(0) to CPU address failed node(/sram@2e000000)
OF: translation of DMA address(0) to CPU address failed node(/uart@7ff80000)
...
OF: translation of DMA address(0) to CPU address failed node(/mhu@2b1f0000)
OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
OF: translation of DMA address(0) to CPU address failed node(/iommu@2b600000)
So let's fix it by dropping the "dma-ranges" property for now. This
should be fine since it doesn't represent any kind of device-visible
restriction; it was only there for completeness, and we've since given
in to the assumption that missing "dma-ranges" implies a 1:1 mapping
anyway.
We can add it later with a proper SoC bus node and moving all the
devices that belong there along with the "dma-ranges" if required.
Fixes: 193d00a2b3 ("arm64: dts: juno: add dma-ranges property")
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a50d45450 upstream.
The "priv->hw_type" is an enum and in this context GCC will treat it
as an unsigned int so the error handling will never trigger.
Fixes: a910e4a94f ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 216808c6ba upstream.
At the time commit ce5ec44099 ("tcp: ensure epoll edge trigger
wakeup when write queue is empty") was added to the kernel,
we still had a single write queue, combining rtx and write queues.
Once we moved the rtx queue into a separate rb-tree, testing
if sk_write_queue is empty has been suboptimal.
Indeed, if we have packets in the rtx queue, we probably want
to delay the EPOLLOUT generation at the time incoming packets
will free them, making room, but more importantly avoiding
flooding application with EPOLLOUT events.
Solution is to use tcp_rtx_and_write_queues_empty() helper.
Fixes: 75c119afe1 ("tcp: implement rb-tree based retransmit queue")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 589b72894f upstream.
Clang warns:
../drivers/block/xen-blkfront.c:1117:4: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
nr_parts = PARTS_PER_DISK;
^
../drivers/block/xen-blkfront.c:1115:3: note: previous statement is here
if (err)
^
This is because there is a space at the beginning of this line; remove
it so that the indentation is consistent according to the Linux kernel
coding style and clang no longer warns.
While we are here, the previous line has some trailing whitespace; clean
that up as well.
Fixes: c80a420995 ("xen-blkfront: handle Xen major numbers other than XENVBD")
Link: https://github.com/ClangBuiltLinux/linux/issues/791
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
