Browse Source

bump to 4.4.52; remove aufs4

parazyd 2 years ago
parent
commit
e2bcb4aa96
100 changed files with 477 additions and 1991 deletions
  1. 0 50
      Documentation/ABI/testing/debugfs-aufs
  2. 0 31
      Documentation/ABI/testing/sysfs-aufs
  3. 0 393
      Documentation/filesystems/aufs/README
  4. 0 170
      Documentation/filesystems/aufs/design/01intro.txt
  5. 0 258
      Documentation/filesystems/aufs/design/02struct.txt
  6. 0 85
      Documentation/filesystems/aufs/design/03atomic_open.txt
  7. 0 113
      Documentation/filesystems/aufs/design/03lookup.txt
  8. 0 74
      Documentation/filesystems/aufs/design/04branch.txt
  9. 0 64
      Documentation/filesystems/aufs/design/05wbr_policy.txt
  10. 0 120
      Documentation/filesystems/aufs/design/06fhsm.txt
  11. 0 72
      Documentation/filesystems/aufs/design/06mmap.txt
  12. 0 96
      Documentation/filesystems/aufs/design/06xattr.txt
  13. 0 58
      Documentation/filesystems/aufs/design/07export.txt
  14. 0 52
      Documentation/filesystems/aufs/design/08shwh.txt
  15. 0 47
      Documentation/filesystems/aufs/design/10dynop.txt
  16. 4 0
      Documentation/kernel-parameters.txt
  17. 0 13
      MAINTAINERS
  18. 1 1
      Makefile
  19. 0 4
      README-heads
  20. 3 1
      arch/arc/include/asm/delay.h
  21. 2 1
      arch/arc/kernel/unaligned.c
  22. 1 1
      arch/arm/kernel/ptrace.c
  23. 1 1
      arch/arm/lib/getuser.S
  24. 2 2
      arch/arm/mm/fault.c
  25. 4 0
      arch/arm/mm/fault.h
  26. 42 46
      arch/arm64/crypto/aes-modes.S
  27. 7 1
      arch/parisc/include/asm/bitops.h
  28. 0 2
      arch/parisc/include/uapi/asm/bitsperlong.h
  29. 3 2
      arch/parisc/include/uapi/asm/swab.h
  30. 1 1
      arch/powerpc/kernel/eeh_driver.c
  31. 3 0
      arch/powerpc/kernel/prom_init.c
  32. 8 0
      arch/s390/kernel/ptrace.c
  33. 1 1
      arch/tile/kernel/ptrace.c
  34. 2 2
      arch/x86/kernel/apic/io_apic.c
  35. 1 0
      arch/x86/kernel/hpet.c
  36. 24 32
      arch/x86/kvm/vmx.c
  37. 1 0
      arch/x86/kvm/x86.c
  38. 13 1
      arch/x86/platform/goldfish/goldfish.c
  39. 8 9
      block/blk-mq.c
  40. 1 0
      crypto/algapi.c
  41. 2 2
      drivers/ata/libata-core.c
  42. 3 0
      drivers/ata/sata_mv.c
  43. 5 6
      drivers/base/memory.c
  44. 0 18
      drivers/block/loop.c
  45. 1 1
      drivers/gpu/drm/drm_dp_mst_topology.c
  46. 7 0
      drivers/gpu/drm/drm_modes.c
  47. 5 4
      drivers/gpu/drm/i915/intel_crt.c
  48. 2 2
      drivers/gpu/drm/i915/intel_display.c
  49. 2 1
      drivers/gpu/drm/nouveau/dispnv04/hw.c
  50. 1 1
      drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c
  51. 2 2
      drivers/gpu/drm/radeon/radeon_cursor.c
  52. 15 13
      drivers/hid/wacom_wac.c
  53. 2 1
      drivers/infiniband/core/cma.c
  54. 2 0
      drivers/infiniband/core/umem.c
  55. 14 6
      drivers/infiniband/ulp/ipoib/ipoib.h
  56. 8 7
      drivers/infiniband/ulp/ipoib/ipoib_cm.c
  57. 5 7
      drivers/infiniband/ulp/ipoib/ipoib_ib.c
  58. 33 21
      drivers/infiniband/ulp/ipoib/ipoib_main.c
  59. 4 2
      drivers/infiniband/ulp/ipoib/ipoib_multicast.c
  60. 1 0
      drivers/input/mouse/elan_i2c_core.c
  61. 2 1
      drivers/isdn/hardware/eicon/message.c
  62. 2 2
      drivers/md/bcache/bcache.h
  63. 20 20
      drivers/md/bcache/btree.c
  64. 1 2
      drivers/md/bcache/btree.h
  65. 1 3
      drivers/md/bcache/request.c
  66. 2 0
      drivers/md/bcache/super.c
  67. 1 0
      drivers/media/i2c/Kconfig
  68. 13 5
      drivers/media/usb/siano/smsusb.c
  69. 2 2
      drivers/mmc/core/mmc.c
  70. 2 1
      drivers/mmc/host/sdhci.c
  71. 1 0
      drivers/net/can/c_can/c_can_pci.c
  72. 12 4
      drivers/net/can/ti_hecc.c
  73. 18 7
      drivers/net/ethernet/broadcom/bcmsysport.c
  74. 2 6
      drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
  75. 4 1
      drivers/net/ethernet/mellanox/mlx4/en_rx.c
  76. 4 4
      drivers/net/ethernet/mellanox/mlxsw/pci.h
  77. 1 0
      drivers/net/ethernet/mellanox/mlxsw/spectrum.c
  78. 1 0
      drivers/net/ethernet/mellanox/mlxsw/switchx2.c
  79. 13 0
      drivers/net/ethernet/renesas/ravb_main.c
  80. 1 1
      drivers/net/hyperv/netvsc_drv.c
  81. 1 0
      drivers/net/loopback.c
  82. 2 2
      drivers/net/macvtap.c
  83. 19 2
      drivers/net/phy/bcm63xx.c
  84. 6 4
      drivers/net/tun.c
  85. 8 0
      drivers/net/usb/cdc_ether.c
  86. 7 0
      drivers/net/usb/qmi_wwan.c
  87. 8 1
      drivers/net/usb/r8152.c
  88. 19 0
      drivers/net/wireless/realtek/rtlwifi/usb.c
  89. 2 1
      drivers/net/xen-netfront.c
  90. 2 3
      drivers/ntb/ntb_transport.c
  91. 13 6
      drivers/pci/pcie/aspm.c
  92. 1 1
      drivers/pinctrl/intel/pinctrl-broxton.c
  93. 8 5
      drivers/platform/goldfish/pdev_bus.c
  94. 1 1
      drivers/platform/x86/intel_mid_powerbtn.c
  95. 15 1
      drivers/rtc/interface.c
  96. 4 4
      drivers/s390/scsi/zfcp_fsf.c
  97. 6 2
      drivers/scsi/aacraid/comminit.c
  98. 3 0
      drivers/scsi/mpt3sas/mpt3sas_scsih.c
  99. 2 1
      drivers/scsi/scsi_lib.c
  100. 0 0
      drivers/scsi/sg.c

+ 0 - 50
Documentation/ABI/testing/debugfs-aufs

@@ -1,50 +0,0 @@
1
-What:		/debug/aufs/si_<id>/
2
-Date:		March 2009
3
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
4
-Description:
5
-		Under /debug/aufs, a directory named si_<id> is created
6
-		per aufs mount, where <id> is a unique id generated
7
-		internally.
8
-
9
-What:		/debug/aufs/si_<id>/plink
10
-Date:		Apr 2013
11
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
12
-Description:
13
-		It has three lines and shows the information about the
14
-		pseudo-link. The first line is a single number
15
-		representing a number of buckets. The second line is a
16
-		number of pseudo-links per buckets (separated by a
17
-		blank). The last line is a single number representing a
18
-		total number of psedo-links.
19
-		When the aufs mount option 'noplink' is specified, it
20
-		will show "1\n0\n0\n".
21
-
22
-What:		/debug/aufs/si_<id>/xib
23
-Date:		March 2009
24
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
25
-Description:
26
-		It shows the consumed blocks by xib (External Inode Number
27
-		Bitmap), its block size and file size.
28
-		When the aufs mount option 'noxino' is specified, it
29
-		will be empty. About XINO files, see the aufs manual.
30
-
31
-What:		/debug/aufs/si_<id>/xino0, xino1 ... xinoN
32
-Date:		March 2009
33
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
34
-Description:
35
-		It shows the consumed blocks by xino (External Inode Number
36
-		Translation Table), its link count, block size and file
37
-		size.
38
-		When the aufs mount option 'noxino' is specified, it
39
-		will be empty. About XINO files, see the aufs manual.
40
-
41
-What:		/debug/aufs/si_<id>/xigen
42
-Date:		March 2009
43
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
44
-Description:
45
-		It shows the consumed blocks by xigen (External Inode
46
-		Generation Table), its block size and file size.
47
-		If CONFIG_AUFS_EXPORT is disabled, this entry will not
48
-		be created.
49
-		When the aufs mount option 'noxino' is specified, it
50
-		will be empty. About XINO files, see the aufs manual.

+ 0 - 31
Documentation/ABI/testing/sysfs-aufs

@@ -1,31 +0,0 @@
1
-What:		/sys/fs/aufs/si_<id>/
2
-Date:		March 2009
3
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
4
-Description:
5
-		Under /sys/fs/aufs, a directory named si_<id> is created
6
-		per aufs mount, where <id> is a unique id generated
7
-		internally.
8
-
9
-What:		/sys/fs/aufs/si_<id>/br0, br1 ... brN
10
-Date:		March 2009
11
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
12
-Description:
13
-		It shows the abolute path of a member directory (which
14
-		is called branch) in aufs, and its permission.
15
-
16
-What:		/sys/fs/aufs/si_<id>/brid0, brid1 ... bridN
17
-Date:		July 2013
18
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
19
-Description:
20
-		It shows the id of a member directory (which is called
21
-		branch) in aufs.
22
-
23
-What:		/sys/fs/aufs/si_<id>/xi_path
24
-Date:		March 2009
25
-Contact:	J. R. Okajima <hooanon05g@gmail.com>
26
-Description:
27
-		It shows the abolute path of XINO (External Inode Number
28
-		Bitmap, Translation Table and Generation Table) file
29
-		even if it is the default path.
30
-		When the aufs mount option 'noxino' is specified, it
31
-		will be empty. About XINO files, see the aufs manual.

+ 0 - 393
Documentation/filesystems/aufs/README

@@ -1,393 +0,0 @@
1
-
2
-Aufs4 -- advanced multi layered unification filesystem version 4.x
3
-http://aufs.sf.net
4
-Junjiro R. Okajima
5
-
6
-
7
-0. Introduction
8
-----------------------------------------
9
-In the early days, aufs was entirely re-designed and re-implemented
10
-Unionfs Version 1.x series. Adding many original ideas, approaches,
11
-improvements and implementations, it becomes totally different from
12
-Unionfs while keeping the basic features.
13
-Recently, Unionfs Version 2.x series begin taking some of the same
14
-approaches to aufs1's.
15
-Unionfs is being developed by Professor Erez Zadok at Stony Brook
16
-University and his team.
17
-
18
-Aufs4 supports linux-4.0 and later, and for linux-3.x series try aufs3.
19
-If you want older kernel version support, try aufs2-2.6.git or
20
-aufs2-standalone.git repository, aufs1 from CVS on SourceForge.
21
-
22
-Note: it becomes clear that "Aufs was rejected. Let's give it up."
23
-      According to Christoph Hellwig, linux rejects all union-type
24
-      filesystems but UnionMount.
25
-<http://marc.info/?l=linux-kernel&m=123938533724484&w=2>
26
-
27
-PS. Al Viro seems have a plan to merge aufs as well as overlayfs and
28
-    UnionMount, and he pointed out an issue around a directory mutex
29
-    lock and aufs addressed it. But it is still unsure whether aufs will
30
-    be merged (or any other union solution).
31
-<http://marc.info/?l=linux-kernel&m=136312705029295&w=1>
32
-
33
-
34
-1. Features
35
-----------------------------------------
36
-- unite several directories into a single virtual filesystem. The member
37
-  directory is called as a branch.
38
-- you can specify the permission flags to the branch, which are 'readonly',
39
-  'readwrite' and 'whiteout-able.'
40
-- by upper writable branch, internal copyup and whiteout, files/dirs on
41
-  readonly branch are modifiable logically.
42
-- dynamic branch manipulation, add, del.
43
-- etc...
44
-
45
-Also there are many enhancements in aufs, such as:
46
-- test only the highest one for the directory permission (dirperm1)
47
-- copyup on open (coo=)
48
-- 'move' policy for copy-up between two writable branches, after
49
-  checking free space.
50
-- xattr, acl
51
-- readdir(3) in userspace.
52
-- keep inode number by external inode number table
53
-- keep the timestamps of file/dir in internal copyup operation
54
-- seekable directory, supporting NFS readdir.
55
-- whiteout is hardlinked in order to reduce the consumption of inodes
56
-  on branch
57
-- do not copyup, nor create a whiteout when it is unnecessary
58
-- revert a single systemcall when an error occurs in aufs
59
-- remount interface instead of ioctl
60
-- maintain /etc/mtab by an external command, /sbin/mount.aufs.
61
-- loopback mounted filesystem as a branch
62
-- kernel thread for removing the dir who has a plenty of whiteouts
63
-- support copyup sparse file (a file which has a 'hole' in it)
64
-- default permission flags for branches
65
-- selectable permission flags for ro branch, whether whiteout can
66
-  exist or not
67
-- export via NFS.
68
-- support <sysfs>/fs/aufs and <debugfs>/aufs.
69
-- support multiple writable branches, some policies to select one
70
-  among multiple writable branches.
71
-- a new semantics for link(2) and rename(2) to support multiple
72
-  writable branches.
73
-- no glibc changes are required.
74
-- pseudo hardlink (hardlink over branches)
75
-- allow a direct access manually to a file on branch, e.g. bypassing aufs.
76
-  including NFS or remote filesystem branch.
77
-- userspace wrapper for pathconf(3)/fpathconf(3) with _PC_LINK_MAX.
78
-- and more...
79
-
80
-Currently these features are dropped temporary from aufs4.
81
-See design/08plan.txt in detail.
82
-- nested mount, i.e. aufs as readonly no-whiteout branch of another aufs
83
-  (robr)
84
-- statistics of aufs thread (/sys/fs/aufs/stat)
85
-
86
-Features or just an idea in the future (see also design/*.txt),
87
-- reorder the branch index without del/re-add.
88
-- permanent xino files for NFSD
89
-- an option for refreshing the opened files after add/del branches
90
-- light version, without branch manipulation. (unnecessary?)
91
-- copyup in userspace
92
-- inotify in userspace
93
-- readv/writev
94
-
95
-
96
-2. Download
97
-----------------------------------------
98
-There are three GIT trees for aufs4, aufs4-linux.git,
99
-aufs4-standalone.git, and aufs-util.git. Note that there is no "4" in
100
-"aufs-util.git."
101
-While the aufs-util is always necessary, you need either of aufs4-linux
102
-or aufs4-standalone.
103
-
104
-The aufs4-linux tree includes the whole linux mainline GIT tree,
105
-git://git.kernel.org/.../torvalds/linux.git.
106
-And you cannot select CONFIG_AUFS_FS=m for this version, eg. you cannot
107
-build aufs4 as an external kernel module.
108
-Several extra patches are not included in this tree. Only
109
-aufs4-standalone tree contains them. They are described in the later
110
-section "Configuration and Compilation."
111
-
112
-On the other hand, the aufs4-standalone tree has only aufs source files
113
-and necessary patches, and you can select CONFIG_AUFS_FS=m.
114
-But you need to apply all aufs patches manually.
115
-
116
-You will find GIT branches whose name is in form of "aufs4.x" where "x"
117
-represents the linux kernel version, "linux-4.x". For instance,
118
-"aufs4.0" is for linux-4.0. For latest "linux-4.x-rcN", use
119
-"aufs4.x-rcN" branch.
120
-
121
-o aufs4-linux tree
122
-$ git clone --reference /your/linux/git/tree \
123
-	git://github.com/sfjro/aufs4-linux.git aufs4-linux.git
124
-- if you don't have linux GIT tree, then remove "--reference ..."
125
-$ cd aufs4-linux.git
126
-$ git checkout origin/aufs4.0
127
-
128
-Or You may want to directly git-pull aufs into your linux GIT tree, and
129
-leave the patch-work to GIT.
130
-$ cd /your/linux/git/tree
131
-$ git remote add aufs4 git://github.com/sfjro/aufs4-linux.git
132
-$ git fetch aufs4
133
-$ git checkout -b my4.0 v4.0
134
-$ (add your local change...)
135
-$ git pull aufs4 aufs4.0
136
-- now you have v4.0 + your_changes + aufs4.0 in you my4.0 branch.
137
-- you may need to solve some conflicts between your_changes and
138
-  aufs4.0. in this case, git-rerere is recommended so that you can
139
-  solve the similar conflicts automatically when you upgrade to 4.1 or
140
-  later in the future.
141
-
142
-o aufs4-standalone tree
143
-$ git clone git://github.com/sfjro/aufs4-standalone.git aufs4-standalone.git
144
-$ cd aufs4-standalone.git
145
-$ git checkout origin/aufs4.0
146
-
147
-o aufs-util tree
148
-$ git clone git://git.code.sf.net/p/aufs/aufs-util aufs-util.git
149
-- note that the public aufs-util.git is on SourceForge instead of
150
-  GitHUB.
151
-$ cd aufs-util.git
152
-$ git checkout origin/aufs4.0
153
-
154
-Note: The 4.x-rcN branch is to be used with `rc' kernel versions ONLY.
155
-The minor version number, 'x' in '4.x', of aufs may not always
156
-follow the minor version number of the kernel.
157
-Because changes in the kernel that cause the use of a new
158
-minor version number do not always require changes to aufs-util.
159
-
160
-Since aufs-util has its own minor version number, you may not be
161
-able to find a GIT branch in aufs-util for your kernel's
162
-exact minor version number.
163
-In this case, you should git-checkout the branch for the
164
-nearest lower number.
165
-
166
-For (an unreleased) example:
167
-If you are using "linux-4.10" and the "aufs4.10" branch
168
-does not exist in aufs-util repository, then "aufs4.9", "aufs4.8"
169
-or something numerically smaller is the branch for your kernel.
170
-
171
-Also you can view all branches by
172
-	$ git branch -a
173
-
174
-
175
-3. Configuration and Compilation
176
-----------------------------------------
177
-Make sure you have git-checkout'ed the correct branch.
178
-
179
-For aufs4-linux tree,
180
-- enable CONFIG_AUFS_FS.
181
-- set other aufs configurations if necessary.
182
-
183
-For aufs4-standalone tree,
184
-There are several ways to build.
185
-
186
-1.
187
-- apply ./aufs4-kbuild.patch to your kernel source files.
188
-- apply ./aufs4-base.patch too.
189
-- apply ./aufs4-mmap.patch too.
190
-- apply ./aufs4-standalone.patch too, if you have a plan to set
191
-  CONFIG_AUFS_FS=m. otherwise you don't need ./aufs4-standalone.patch.
192
-- copy ./{Documentation,fs,include/uapi/linux/aufs_type.h} files to your
193
-  kernel source tree. Never copy $PWD/include/uapi/linux/Kbuild.
194
-- enable CONFIG_AUFS_FS, you can select either
195
-  =m or =y.
196
-- and build your kernel as usual.
197
-- install the built kernel.
198
-  Note: Since linux-3.9, every filesystem module requires an alias
199
-  "fs-<fsname>". You should make sure that "fs-aufs" is listed in your
200
-  modules.aliases file if you set CONFIG_AUFS_FS=m.
201
-- install the header files too by "make headers_install" to the
202
-  directory where you specify. By default, it is $PWD/usr.
203
-  "make help" shows a brief note for headers_install.
204
-- and reboot your system.
205
-
206
-2.
207
-- module only (CONFIG_AUFS_FS=m).
208
-- apply ./aufs4-base.patch to your kernel source files.
209
-- apply ./aufs4-mmap.patch too.
210
-- apply ./aufs4-standalone.patch too.
211
-- build your kernel, don't forget "make headers_install", and reboot.
212
-- edit ./config.mk and set other aufs configurations if necessary.
213
-  Note: You should read $PWD/fs/aufs/Kconfig carefully which describes
214
-  every aufs configurations.
215
-- build the module by simple "make".
216
-  Note: Since linux-3.9, every filesystem module requires an alias
217
-  "fs-<fsname>". You should make sure that "fs-aufs" is listed in your
218
-  modules.aliases file.
219
-- you can specify ${KDIR} make variable which points to your kernel
220
-  source tree.
221
-- install the files
222
-  + run "make install" to install the aufs module, or copy the built
223
-    $PWD/aufs.ko to /lib/modules/... and run depmod -a (or reboot simply).
224
-  + run "make install_headers" (instead of headers_install) to install
225
-    the modified aufs header file (you can specify DESTDIR which is
226
-    available in aufs standalone version's Makefile only), or copy
227
-    $PWD/usr/include/linux/aufs_type.h to /usr/include/linux or wherever
228
-    you like manually. By default, the target directory is $PWD/usr.
229
-- no need to apply aufs4-kbuild.patch, nor copying source files to your
230
-  kernel source tree.
231
-
232
-Note: The header file aufs_type.h is necessary to build aufs-util
233
-      as well as "make headers_install" in the kernel source tree.
234
-      headers_install is subject to be forgotten, but it is essentially
235
-      necessary, not only for building aufs-util.
236
-      You may not meet problems without headers_install in some older
237
-      version though.
238
-
239
-And then,
240
-- read README in aufs-util, build and install it
241
-- note that your distribution may contain an obsoleted version of
242
-  aufs_type.h in /usr/include/linux or something. When you build aufs
243
-  utilities, make sure that your compiler refers the correct aufs header
244
-  file which is built by "make headers_install."
245
-- if you want to use readdir(3) in userspace or pathconf(3) wrapper,
246
-  then run "make install_ulib" too. And refer to the aufs manual in
247
-  detail.
248
-
249
-There several other patches in aufs4-standalone.git. They are all
250
-optional. When you meet some problems, they will help you.
251
-- aufs4-loopback.patch
252
-  Supports a nested loopback mount in a branch-fs. This patch is
253
-  unnecessary until aufs produces a message like "you may want to try
254
-  another patch for loopback file".
255
-- vfs-ino.patch
256
-  Modifies a system global kernel internal function get_next_ino() in
257
-  order to stop assigning 0 for an inode-number. Not directly related to
258
-  aufs, but recommended generally.
259
-- tmpfs-idr.patch
260
-  Keeps the tmpfs inode number as the lowest value. Effective to reduce
261
-  the size of aufs XINO files for tmpfs branch. Also it prevents the
262
-  duplication of inode number, which is important for backup tools and
263
-  other utilities. When you find aufs XINO files for tmpfs branch
264
-  growing too much, try this patch.
265
-- lockdep-debug.patch
266
-  Because aufs is not only an ordinary filesystem (callee of VFS), but
267
-  also a caller of VFS functions for branch filesystems, subclassing of
268
-  the internal locks for LOCKDEP is necessary. LOCKDEP is a debugging
269
-  feature of linux kernel. If you enable CONFIG_LOCKDEP, then you will
270
-  need to apply this debug patch to expand several constant values.
271
-  If don't know what LOCKDEP, then you don't have apply this patch.
272
-
273
-
274
-4. Usage
275
-----------------------------------------
276
-At first, make sure aufs-util are installed, and please read the aufs
277
-manual, aufs.5 in aufs-util.git tree.
278
-$ man -l aufs.5
279
-
280
-And then,
281
-$ mkdir /tmp/rw /tmp/aufs
282
-# mount -t aufs -o br=/tmp/rw:${HOME} none /tmp/aufs
283
-
284
-Here is another example. The result is equivalent.
285
-# mount -t aufs -o br=/tmp/rw=rw:${HOME}=ro none /tmp/aufs
286
-  Or
287
-# mount -t aufs -o br:/tmp/rw none /tmp/aufs
288
-# mount -o remount,append:${HOME} /tmp/aufs
289
-
290
-Then, you can see whole tree of your home dir through /tmp/aufs. If
291
-you modify a file under /tmp/aufs, the one on your home directory is
292
-not affected, instead the same named file will be newly created under
293
-/tmp/rw. And all of your modification to a file will be applied to
294
-the one under /tmp/rw. This is called the file based Copy on Write
295
-(COW) method.
296
-Aufs mount options are described in aufs.5.
297
-If you run chroot or something and make your aufs as a root directory,
298
-then you need to customize the shutdown script. See the aufs manual in
299
-detail.
300
-
301
-Additionally, there are some sample usages of aufs which are a
302
-diskless system with network booting, and LiveCD over NFS.
303
-See sample dir in CVS tree on SourceForge.
304
-
305
-
306
-5. Contact
307
-----------------------------------------
308
-When you have any problems or strange behaviour in aufs, please let me
309
-know with:
310
-- /proc/mounts (instead of the output of mount(8))
311
-- /sys/module/aufs/*
312
-- /sys/fs/aufs/* (if you have them)
313
-- /debug/aufs/* (if you have them)
314
-- linux kernel version
315
-  if your kernel is not plain, for example modified by distributor,
316
-  the url where i can download its source is necessary too.
317
-- aufs version which was printed at loading the module or booting the
318
-  system, instead of the date you downloaded.
319
-- configuration (define/undefine CONFIG_AUFS_xxx)
320
-- kernel configuration or /proc/config.gz (if you have it)
321
-- behaviour which you think to be incorrect
322
-- actual operation, reproducible one is better
323
-- mailto: aufs-users at lists.sourceforge.net
324
-
325
-Usually, I don't watch the Public Areas(Bugs, Support Requests, Patches,
326
-and Feature Requests) on SourceForge. Please join and write to
327
-aufs-users ML.
328
-
329
-
330
-6. Acknowledgements
331
-----------------------------------------
332
-Thanks to everyone who have tried and are using aufs, whoever
333
-have reported a bug or any feedback.
334
-
335
-Especially donators:
336
-Tomas Matejicek(slax.org) made a donation (much more than once).
337
-	Since Apr 2010, Tomas M (the author of Slax and Linux Live
338
-	scripts) is making "doubling" donations.
339
-	Unfortunately I cannot list all of the donators, but I really
340
-	appreciate.
341
-	It ends Aug 2010, but the ordinary donation URL is still available.
342
-	<http://sourceforge.net/donate/index.php?group_id=167503>
343
-Dai Itasaka made a donation (2007/8).
344
-Chuck Smith made a donation (2008/4, 10 and 12).
345
-Henk Schoneveld made a donation (2008/9).
346
-Chih-Wei Huang, ASUS, CTC donated Eee PC 4G (2008/10).
347
-Francois Dupoux made a donation (2008/11).
348
-Bruno Cesar Ribas and Luis Carlos Erpen de Bona, C3SL serves public
349
-	aufs2 GIT tree (2009/2).
350
-William Grant made a donation (2009/3).
351
-Patrick Lane made a donation (2009/4).
352
-The Mail Archive (mail-archive.com) made donations (2009/5).
353
-Nippy Networks (Ed Wildgoose) made a donation (2009/7).
354
-New Dream Network, LLC (www.dreamhost.com) made a donation (2009/11).
355
-Pavel Pronskiy made a donation (2011/2).
356
-Iridium and Inmarsat satellite phone retailer (www.mailasail.com), Nippy
357
-	Networks (Ed Wildgoose) made a donation for hardware (2011/3).
358
-Max Lekomcev (DOM-TV project) made a donation (2011/7, 12, 2012/3, 6 and
359
-11).
360
-Sam Liddicott made a donation (2011/9).
361
-Era Scarecrow made a donation (2013/4).
362
-Bor Ratajc made a donation (2013/4).
363
-Alessandro Gorreta made a donation (2013/4).
364
-POIRETTE Marc made a donation (2013/4).
365
-Alessandro Gorreta made a donation (2013/4).
366
-lauri kasvandik made a donation (2013/5).
367
-"pemasu from Finland" made a donation (2013/7).
368
-The Parted Magic Project made a donation (2013/9 and 11).
369
-Pavel Barta made a donation (2013/10).
370
-Nikolay Pertsev made a donation (2014/5).
371
-James B made a donation (2014/7 and 2015/7).
372
-Stefano Di Biase made a donation (2014/8).
373
-Daniel Epellei made a donation (2015/1).
374
-OmegaPhil made a donation (2016/1).
375
-Tomasz Szewczyk made a donation (2016/4).
376
-James Burry made a donation (2016/12).
377
-
378
-Thank you very much.
379
-Donations are always, including future donations, very important and
380
-helpful for me to keep on developing aufs.
381
-
382
-
383
-7.
384
-----------------------------------------
385
-If you are an experienced user, no explanation is needed. Aufs is
386
-just a linux filesystem.
387
-
388
-
389
-Enjoy!
390
-
391
-# Local variables: ;
392
-# mode: text;
393
-# End: ;

+ 0 - 170
Documentation/filesystems/aufs/design/01intro.txt

@@ -1,170 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Introduction
18
-----------------------------------------
19
-
20
-aufs [ei ju: ef es] | [a u f s]
21
-1. abbrev. for "advanced multi-layered unification filesystem".
22
-2. abbrev. for "another unionfs".
23
-3. abbrev. for "auf das" in German which means "on the" in English.
24
-   Ex. "Butter aufs Brot"(G) means "butter onto bread"(E).
25
-   But "Filesystem aufs Filesystem" is hard to understand.
26
-
27
-AUFS is a filesystem with features:
28
-- multi layered stackable unification filesystem, the member directory
29
-  is called as a branch.
30
-- branch permission and attribute, 'readonly', 'real-readonly',
31
-  'readwrite', 'whiteout-able', 'link-able whiteout', etc. and their
32
-  combination.
33
-- internal "file copy-on-write".
34
-- logical deletion, whiteout.
35
-- dynamic branch manipulation, adding, deleting and changing permission.
36
-- allow bypassing aufs, user's direct branch access.
37
-- external inode number translation table and bitmap which maintains the
38
-  persistent aufs inode number.
39
-- seekable directory, including NFS readdir.
40
-- file mapping, mmap and sharing pages.
41
-- pseudo-link, hardlink over branches.
42
-- loopback mounted filesystem as a branch.
43
-- several policies to select one among multiple writable branches.
44
-- revert a single systemcall when an error occurs in aufs.
45
-- and more...
46
-
47
-
48
-Multi Layered Stackable Unification Filesystem
49
-----------------------------------------------------------------------
50
-Most people already knows what it is.
51
-It is a filesystem which unifies several directories and provides a
52
-merged single directory. When users access a file, the access will be
53
-passed/re-directed/converted (sorry, I am not sure which English word is
54
-correct) to the real file on the member filesystem. The member
55
-filesystem is called 'lower filesystem' or 'branch' and has a mode
56
-'readonly' and 'readwrite.' And the deletion for a file on the lower
57
-readonly branch is handled by creating 'whiteout' on the upper writable
58
-branch.
59
-
60
-On LKML, there have been discussions about UnionMount (Jan Blunck,
61
-Bharata B Rao and Valerie Aurora) and Unionfs (Erez Zadok). They took
62
-different approaches to implement the merged-view.
63
-The former tries putting it into VFS, and the latter implements as a
64
-separate filesystem.
65
-(If I misunderstand about these implementations, please let me know and
66
-I shall correct it. Because it is a long time ago when I read their
67
-source files last time).
68
-
69
-UnionMount's approach will be able to small, but may be hard to share
70
-branches between several UnionMount since the whiteout in it is
71
-implemented in the inode on branch filesystem and always
72
-shared. According to Bharata's post, readdir does not seems to be
73
-finished yet.
74
-There are several missing features known in this implementations such as
75
-- for users, the inode number may change silently. eg. copy-up.
76
-- link(2) may break by copy-up.
77
-- read(2) may get an obsoleted filedata (fstat(2) too).
78
-- fcntl(F_SETLK) may be broken by copy-up.
79
-- unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after
80
-  open(O_RDWR).
81
-
82
-In linux-3.18, "overlay" filesystem (formerly known as "overlayfs") was
83
-merged into mainline. This is another implementation of UnionMount as a
84
-separated filesystem. All the limitations and known problems which
85
-UnionMount are equally inherited to "overlay" filesystem.
86
-
87
-Unionfs has a longer history. When I started implementing a stackable
88
-filesystem (Aug 2005), it already existed. It has virtual super_block,
89
-inode, dentry and file objects and they have an array pointing lower
90
-same kind objects. After contributing many patches for Unionfs, I
91
-re-started my project AUFS (Jun 2006).
92
-
93
-In AUFS, the structure of filesystem resembles to Unionfs, but I
94
-implemented my own ideas, approaches and enhancements and it became
95
-totally different one.
96
-
97
-Comparing DM snapshot and fs based implementation
98
-- the number of bytes to be copied between devices is much smaller.
99
-- the type of filesystem must be one and only.
100
-- the fs must be writable, no readonly fs, even for the lower original
101
-  device. so the compression fs will not be usable. but if we use
102
-  loopback mount, we may address this issue.
103
-  for instance,
104
-	mount /cdrom/squashfs.img /sq
105
-	losetup /sq/ext2.img
106
-	losetup /somewhere/cow
107
-	dmsetup "snapshot /dev/loop0 /dev/loop1 ..."
108
-- it will be difficult (or needs more operations) to extract the
109
-  difference between the original device and COW.
110
-- DM snapshot-merge may help a lot when users try merging. in the
111
-  fs-layer union, users will use rsync(1).
112
-
113
-You may want to read my old paper "Filesystems in LiveCD"
114
-(http://aufs.sourceforge.net/aufs2/report/sq/sq.pdf).
115
-
116
-
117
-Several characters/aspects/persona of aufs
118
-----------------------------------------------------------------------
119
-
120
-Aufs has several characters, aspects or persona.
121
-1. a filesystem, callee of VFS helper
122
-2. sub-VFS, caller of VFS helper for branches
123
-3. a virtual filesystem which maintains persistent inode number
124
-4. reader/writer of files on branches such like an application
125
-
126
-1. Callee of VFS Helper
127
-As an ordinary linux filesystem, aufs is a callee of VFS. For instance,
128
-unlink(2) from an application reaches sys_unlink() kernel function and
129
-then vfs_unlink() is called. vfs_unlink() is one of VFS helper and it
130
-calls filesystem specific unlink operation. Actually aufs implements the
131
-unlink operation but it behaves like a redirector.
132
-
133
-2. Caller of VFS Helper for Branches
134
-aufs_unlink() passes the unlink request to the branch filesystem as if
135
-it were called from VFS. So the called unlink operation of the branch
136
-filesystem acts as usual. As a caller of VFS helper, aufs should handle
137
-every necessary pre/post operation for the branch filesystem.
138
-- acquire the lock for the parent dir on a branch
139
-- lookup in a branch
140
-- revalidate dentry on a branch
141
-- mnt_want_write() for a branch
142
-- vfs_unlink() for a branch
143
-- mnt_drop_write() for a branch
144
-- release the lock on a branch
145
-
146
-3. Persistent Inode Number
147
-One of the most important issue for a filesystem is to maintain inode
148
-numbers. This is particularly important to support exporting a
149
-filesystem via NFS. Aufs is a virtual filesystem which doesn't have a
150
-backend block device for its own. But some storage is necessary to
151
-keep and maintain the inode numbers. It may be a large space and may not
152
-suit to keep in memory. Aufs rents some space from its first writable
153
-branch filesystem (by default) and creates file(s) on it. These files
154
-are created by aufs internally and removed soon (currently) keeping
155
-opened.
156
-Note: Because these files are removed, they are totally gone after
157
-      unmounting aufs. It means the inode numbers are not persistent
158
-      across unmount or reboot. I have a plan to make them really
159
-      persistent which will be important for aufs on NFS server.
160
-
161
-4. Read/Write Files Internally (copy-on-write)
162
-Because a branch can be readonly, when you write a file on it, aufs will
163
-"copy-up" it to the upper writable branch internally. And then write the
164
-originally requested thing to the file. Generally kernel doesn't
165
-open/read/write file actively. In aufs, even a single write may cause a
166
-internal "file copy". This behaviour is very similar to cp(1) command.
167
-
168
-Some people may think it is better to pass such work to user space
169
-helper, instead of doing in kernel space. Actually I am still thinking
170
-about it. But currently I have implemented it in kernel space.

+ 0 - 258
Documentation/filesystems/aufs/design/02struct.txt

@@ -1,258 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Basic Aufs Internal Structure
18
-
19
-Superblock/Inode/Dentry/File Objects
20
-----------------------------------------------------------------------
21
-As like an ordinary filesystem, aufs has its own
22
-superblock/inode/dentry/file objects. All these objects have a
23
-dynamically allocated array and store the same kind of pointers to the
24
-lower filesystem, branch.
25
-For example, when you build a union with one readwrite branch and one
26
-readonly, mounted /au, /rw and /ro respectively.
27
-- /au = /rw + /ro
28
-- /ro/fileA exists but /rw/fileA
29
-
30
-Aufs lookup operation finds /ro/fileA and gets dentry for that. These
31
-pointers are stored in a aufs dentry. The array in aufs dentry will be,
32
-- [0] = NULL (because /rw/fileA doesn't exist)
33
-- [1] = /ro/fileA
34
-
35
-This style of an array is essentially same to the aufs
36
-superblock/inode/dentry/file objects.
37
-
38
-Because aufs supports manipulating branches, ie. add/delete/change
39
-branches dynamically, these objects has its own generation. When
40
-branches are changed, the generation in aufs superblock is
41
-incremented. And a generation in other object are compared when it is
42
-accessed. When a generation in other objects are obsoleted, aufs
43
-refreshes the internal array.
44
-
45
-
46
-Superblock
47
-----------------------------------------------------------------------
48
-Additionally aufs superblock has some data for policies to select one
49
-among multiple writable branches, XIB files, pseudo-links and kobject.
50
-See below in detail.
51
-About the policies which supports copy-down a directory, see
52
-wbr_policy.txt too.
53
-
54
-
55
-Branch and XINO(External Inode Number Translation Table)
56
-----------------------------------------------------------------------
57
-Every branch has its own xino (external inode number translation table)
58
-file. The xino file is created and unlinked by aufs internally. When two
59
-members of a union exist on the same filesystem, they share the single
60
-xino file.
61
-The struct of a xino file is simple, just a sequence of aufs inode
62
-numbers which is indexed by the lower inode number.
63
-In the above sample, assume the inode number of /ro/fileA is i111 and
64
-aufs assigns the inode number i999 for fileA. Then aufs writes 999 as
65
-4(8) bytes at 111 * 4(8) bytes offset in the xino file.
66
-
67
-When the inode numbers are not contiguous, the xino file will be sparse
68
-which has a hole in it and doesn't consume as much disk space as it
69
-might appear. If your branch filesystem consumes disk space for such
70
-holes, then you should specify 'xino=' option at mounting aufs.
71
-
72
-Aufs has a mount option to free the disk blocks for such holes in XINO
73
-files on tmpfs or ramdisk. But it is not so effective actually. If you
74
-meet a problem of disk shortage due to XINO files, then you should try
75
-"tmpfs-ino.patch" (and "vfs-ino.patch" too) in aufs4-standalone.git.
76
-The patch localizes the assignment inumbers per tmpfs-mount and avoid
77
-the holes in XINO files.
78
-
79
-Also a writable branch has three kinds of "whiteout bases". All these
80
-are existed when the branch is joined to aufs, and their names are
81
-whiteout-ed doubly, so that users will never see their names in aufs
82
-hierarchy.
83
-1. a regular file which will be hardlinked to all whiteouts.
84
-2. a directory to store a pseudo-link.
85
-3. a directory to store an "orphan"-ed file temporary.
86
-
87
-1. Whiteout Base
88
-   When you remove a file on a readonly branch, aufs handles it as a
89
-   logical deletion and creates a whiteout on the upper writable branch
90
-   as a hardlink of this file in order not to consume inode on the
91
-   writable branch.
92
-2. Pseudo-link Dir
93
-   See below, Pseudo-link.
94
-3. Step-Parent Dir
95
-   When "fileC" exists on the lower readonly branch only and it is
96
-   opened and removed with its parent dir, and then user writes
97
-   something into it, then aufs copies-up fileC to this
98
-   directory. Because there is no other dir to store fileC. After
99
-   creating a file under this dir, the file is unlinked.
100
-
101
-Because aufs supports manipulating branches, ie. add/delete/change
102
-dynamically, a branch has its own id. When the branch order changes,
103
-aufs finds the new index by searching the branch id.
104
-
105
-
106
-Pseudo-link
107
-----------------------------------------------------------------------
108
-Assume "fileA" exists on the lower readonly branch only and it is
109
-hardlinked to "fileB" on the branch. When you write something to fileA,
110
-aufs copies-up it to the upper writable branch. Additionally aufs
111
-creates a hardlink under the Pseudo-link Directory of the writable
112
-branch. The inode of a pseudo-link is kept in aufs super_block as a
113
-simple list. If fileB is read after unlinking fileA, aufs returns
114
-filedata from the pseudo-link instead of the lower readonly
115
-branch. Because the pseudo-link is based upon the inode, to keep the
116
-inode number by xino (see above) is essentially necessary.
117
-
118
-All the hardlinks under the Pseudo-link Directory of the writable branch
119
-should be restored in a proper location later. Aufs provides a utility
120
-to do this. The userspace helpers executed at remounting and unmounting
121
-aufs by default.
122
-During this utility is running, it puts aufs into the pseudo-link
123
-maintenance mode. In this mode, only the process which began the
124
-maintenance mode (and its child processes) is allowed to operate in
125
-aufs. Some other processes which are not related to the pseudo-link will
126
-be allowed to run too, but the rest have to return an error or wait
127
-until the maintenance mode ends. If a process already acquires an inode
128
-mutex (in VFS), it has to return an error.
129
-
130
-
131
-XIB(external inode number bitmap)
132
-----------------------------------------------------------------------
133
-Addition to the xino file per a branch, aufs has an external inode number
134
-bitmap in a superblock object. It is also an internal file such like a
135
-xino file.
136
-It is a simple bitmap to mark whether the aufs inode number is in-use or
137
-not.
138
-To reduce the file I/O, aufs prepares a single memory page to cache xib.
139
-
140
-As well as XINO files, aufs has a feature to truncate/refresh XIB to
141
-reduce the number of consumed disk blocks for these files.
142
-
143
-
144
-Virtual or Vertical Dir, and Readdir in Userspace
145
-----------------------------------------------------------------------
146
-In order to support multiple layers (branches), aufs readdir operation
147
-constructs a virtual dir block on memory. For readdir, aufs calls
148
-vfs_readdir() internally for each dir on branches, merges their entries
149
-with eliminating the whiteout-ed ones, and sets it to file (dir)
150
-object. So the file object has its entry list until it is closed. The
151
-entry list will be updated when the file position is zero and becomes
152
-obsoleted. This decision is made in aufs automatically.
153
-
154
-The dynamically allocated memory block for the name of entries has a
155
-unit of 512 bytes (by default) and stores the names contiguously (no
156
-padding). Another block for each entry is handled by kmem_cache too.
157
-During building dir blocks, aufs creates hash list and judging whether
158
-the entry is whiteouted by its upper branch or already listed.
159
-The merged result is cached in the corresponding inode object and
160
-maintained by a customizable life-time option.
161
-
162
-Some people may call it can be a security hole or invite DoS attack
163
-since the opened and once readdir-ed dir (file object) holds its entry
164
-list and becomes a pressure for system memory. But I'd say it is similar
165
-to files under /proc or /sys. The virtual files in them also holds a
166
-memory page (generally) while they are opened. When an idea to reduce
167
-memory for them is introduced, it will be applied to aufs too.
168
-For those who really hate this situation, I've developed readdir(3)
169
-library which operates this merging in userspace. You just need to set
170
-LD_PRELOAD environment variable, and aufs will not consume no memory in
171
-kernel space for readdir(3).
172
-
173
-
174
-Workqueue
175
-----------------------------------------------------------------------
176
-Aufs sometimes requires privilege access to a branch. For instance,
177
-in copy-up/down operation. When a user process is going to make changes
178
-to a file which exists in the lower readonly branch only, and the mode
179
-of one of ancestor directories may not be writable by a user
180
-process. Here aufs copy-up the file with its ancestors and they may
181
-require privilege to set its owner/group/mode/etc.
182
-This is a typical case of a application character of aufs (see
183
-Introduction).
184
-
185
-Aufs uses workqueue synchronously for this case. It creates its own
186
-workqueue. The workqueue is a kernel thread and has privilege. Aufs
187
-passes the request to call mkdir or write (for example), and wait for
188
-its completion. This approach solves a problem of a signal handler
189
-simply.
190
-If aufs didn't adopt the workqueue and changed the privilege of the
191
-process, then the process may receive the unexpected SIGXFSZ or other
192
-signals.
193
-
194
-Also aufs uses the system global workqueue ("events" kernel thread) too
195
-for asynchronous tasks, such like handling inotify/fsnotify, re-creating a
196
-whiteout base and etc. This is unrelated to a privilege.
197
-Most of aufs operation tries acquiring a rw_semaphore for aufs
198
-superblock at the beginning, at the same time waits for the completion
199
-of all queued asynchronous tasks.
200
-
201
-
202
-Whiteout
203
-----------------------------------------------------------------------
204
-The whiteout in aufs is very similar to Unionfs's. That is represented
205
-by its filename. UnionMount takes an approach of a file mode, but I am
206
-afraid several utilities (find(1) or something) will have to support it.
207
-
208
-Basically the whiteout represents "logical deletion" which stops aufs to
209
-lookup further, but also it represents "dir is opaque" which also stop
210
-further lookup.
211
-
212
-In aufs, rmdir(2) and rename(2) for dir uses whiteout alternatively.
213
-In order to make several functions in a single systemcall to be
214
-revertible, aufs adopts an approach to rename a directory to a temporary
215
-unique whiteouted name.
216
-For example, in rename(2) dir where the target dir already existed, aufs
217
-renames the target dir to a temporary unique whiteouted name before the
218
-actual rename on a branch, and then handles other actions (make it opaque,
219
-update the attributes, etc). If an error happens in these actions, aufs
220
-simply renames the whiteouted name back and returns an error. If all are
221
-succeeded, aufs registers a function to remove the whiteouted unique
222
-temporary name completely and asynchronously to the system global
223
-workqueue.
224
-
225
-
226
-Copy-up
227
-----------------------------------------------------------------------
228
-It is a well-known feature or concept.
229
-When user modifies a file on a readonly branch, aufs operate "copy-up"
230
-internally and makes change to the new file on the upper writable branch.
231
-When the trigger systemcall does not update the timestamps of the parent
232
-dir, aufs reverts it after copy-up.
233
-
234
-
235
-Move-down (aufs3.9 and later)
236
-----------------------------------------------------------------------
237
-"Copy-up" is one of the essential feature in aufs. It copies a file from
238
-the lower readonly branch to the upper writable branch when a user
239
-changes something about the file.
240
-"Move-down" is an opposite action of copy-up. Basically this action is
241
-ran manually instead of automatically and internally.
242
-For desgin and implementation, aufs has to consider these issues.
243
-- whiteout for the file may exist on the lower branch.
244
-- ancestor directories may not exist on the lower branch.
245
-- diropq for the ancestor directories may exist on the upper branch.
246
-- free space on the lower branch will reduce.
247
-- another access to the file may happen during moving-down, including
248
-  UDBA (see "Revalidate Dentry and UDBA").
249
-- the file should not be hard-linked nor pseudo-linked. they should be
250
-  handled by auplink utility later.
251
-
252
-Sometimes users want to move-down a file from the upper writable branch
253
-to the lower readonly or writable branch. For instance,
254
-- the free space of the upper writable branch is going to run out.
255
-- create a new intermediate branch between the upper and lower branch.
256
-- etc.
257
-
258
-For this purpose, use "aumvdown" command in aufs-util.git.

+ 0 - 85
Documentation/filesystems/aufs/design/03atomic_open.txt

@@ -1,85 +0,0 @@
1
-
2
-# Copyright (C) 2015-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Support for a branch who has its ->atomic_open()
18
-----------------------------------------------------------------------
19
-The filesystems who implement its ->atomic_open() are not majority. For
20
-example NFSv4 does, and aufs should call NFSv4 ->atomic_open,
21
-particularly for open(O_CREAT|O_EXCL, 0400) case. Other than
22
-->atomic_open(), NFSv4 returns an error for this open(2). While I am not
23
-sure whether all filesystems who have ->atomic_open() behave like this,
24
-but NFSv4 surely returns the error.
25
-
26
-In order to support ->atomic_open() for aufs, there are a few
27
-approaches.
28
-
29
-A. Introduce aufs_atomic_open()
30
-   - calls one of VFS:do_last(), lookup_open() or atomic_open() for
31
-     branch fs.
32
-B. Introduce aufs_atomic_open() calling create, open and chmod. this is
33
-   an aufs user Pip Cet's approach
34
-   - calls aufs_create(), VFS finish_open() and notify_change().
35
-   - pass fake-mode to finish_open(), and then correct the mode by
36
-     notify_change().
37
-C. Extend aufs_open() to call branch fs's ->atomic_open()
38
-   - no aufs_atomic_open().
39
-   - aufs_lookup() registers the TID to an aufs internal object.
40
-   - aufs_create() does nothing when the matching TID is registered, but
41
-     registers the mode.
42
-   - aufs_open() calls branch fs's ->atomic_open() when the matching
43
-     TID is registered.
44
-D. Extend aufs_open() to re-try branch fs's ->open() with superuser's
45
-   credential
46
-   - no aufs_atomic_open().
47
-   - aufs_create() registers the TID to an internal object. this info
48
-     represents "this process created this file just now."
49
-   - when aufs gets EACCES from branch fs's ->open(), then confirm the
50
-     registered TID and re-try open() with superuser's credential.
51
-
52
-Pros and cons for each approach.
53
-
54
-A.
55
-   - straightforward but highly depends upon VFS internal.
56
-   - the atomic behavaiour is kept.
57
-   - some of parameters such as nameidata are hard to reproduce for
58
-     branch fs.
59
-   - large overhead.
60
-B.
61
-   - easy to implement.
62
-   - the atomic behavaiour is lost.
63
-C.
64
-   - the atomic behavaiour is kept.
65
-   - dirty and tricky.
66
-   - VFS checks whether the file is created correctly after calling
67
-     ->create(), which means this approach doesn't work.
68
-D.
69
-   - easy to implement.
70
-   - the atomic behavaiour is lost.
71
-   - to open a file with superuser's credential and give it to a user
72
-     process is a bad idea, since the file object keeps the credential
73
-     in it. It may affect LSM or something. This approach doesn't work
74
-     either.
75
-
76
-The approach A is ideal, but it hard to implement. So here is a
77
-variation of A, which is to be implemented.
78
-
79
-A-1. Introduce aufs_atomic_open()
80
-     - calls branch fs ->atomic_open() if exists. otherwise calls
81
-       vfs_create() and finish_open().
82
-     - the demerit is that the several checks after branch fs
83
-       ->atomic_open() are lost. in the ordinary case, the checks are
84
-       done by VFS:do_last(), lookup_open() and atomic_open(). some can
85
-       be implemented in aufs, but not all I am afraid.

+ 0 - 113
Documentation/filesystems/aufs/design/03lookup.txt

@@ -1,113 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Lookup in a Branch
18
-----------------------------------------------------------------------
19
-Since aufs has a character of sub-VFS (see Introduction), it operates
20
-lookup for branches as VFS does. It may be a heavy work. But almost all
21
-lookup operation in aufs is the simplest case, ie. lookup only an entry
22
-directly connected to its parent. Digging down the directory hierarchy
23
-is unnecessary. VFS has a function lookup_one_len() for that use, and
24
-aufs calls it.
25
-
26
-When a branch is a remote filesystem, aufs basically relies upon its
27
-->d_revalidate(), also aufs forces the hardest revalidate tests for
28
-them.
29
-For d_revalidate, aufs implements three levels of revalidate tests. See
30
-"Revalidate Dentry and UDBA" in detail.
31
-
32
-
33
-Test Only the Highest One for the Directory Permission (dirperm1 option)
34
-----------------------------------------------------------------------
35
-Let's try case study.
36
-- aufs has two branches, upper readwrite and lower readonly.
37
-  /au = /rw + /ro
38
-- "dirA" exists under /ro, but /rw. and its mode is 0700.
39
-- user invoked "chmod a+rx /au/dirA"
40
-- the internal copy-up is activated and "/rw/dirA" is created and its
41
-  permission bits are set to world readable.
42
-- then "/au/dirA" becomes world readable?
43
-
44
-In this case, /ro/dirA is still 0700 since it exists in readonly branch,
45
-or it may be a natively readonly filesystem. If aufs respects the lower
46
-branch, it should not respond readdir request from other users. But user
47
-allowed it by chmod. Should really aufs rejects showing the entries
48
-under /ro/dirA?
49
-
50
-To be honest, I don't have a good solution for this case. So aufs
51
-implements 'dirperm1' and 'nodirperm1' mount options, and leave it to
52
-users.
53
-When dirperm1 is specified, aufs checks only the highest one for the
54
-directory permission, and shows the entries. Otherwise, as usual, checks
55
-every dir existing on all branches and rejects the request.
56
-
57
-As a side effect, dirperm1 option improves the performance of aufs
58
-because the number of permission check is reduced when the number of
59
-branch is many.
60
-
61
-
62
-Revalidate Dentry and UDBA (User's Direct Branch Access)
63
-----------------------------------------------------------------------
64
-Generally VFS helpers re-validate a dentry as a part of lookup.
65
-0. digging down the directory hierarchy.
66
-1. lock the parent dir by its i_mutex.
67
-2. lookup the final (child) entry.
68
-3. revalidate it.
69
-4. call the actual operation (create, unlink, etc.)
70
-5. unlock the parent dir
71
-
72
-If the filesystem implements its ->d_revalidate() (step 3), then it is
73
-called. Actually aufs implements it and checks the dentry on a branch is
74
-still valid.
75
-But it is not enough. Because aufs has to release the lock for the
76
-parent dir on a branch at the end of ->lookup() (step 2) and
77
-->d_revalidate() (step 3) while the i_mutex of the aufs dir is still
78
-held by VFS.
79
-If the file on a branch is changed directly, eg. bypassing aufs, after
80
-aufs released the lock, then the subsequent operation may cause
81
-something unpleasant result.
82
-
83
-This situation is a result of VFS architecture, ->lookup() and
84
-->d_revalidate() is separated. But I never say it is wrong. It is a good
85
-design from VFS's point of view. It is just not suitable for sub-VFS
86
-character in aufs.
87
-
88
-Aufs supports such case by three level of revalidation which is
89
-selectable by user.
90
-1. Simple Revalidate
91
-   Addition to the native flow in VFS's, confirm the child-parent
92
-   relationship on the branch just after locking the parent dir on the
93
-   branch in the "actual operation" (step 4). When this validation
94
-   fails, aufs returns EBUSY. ->d_revalidate() (step 3) in aufs still
95
-   checks the validation of the dentry on branches.
96
-2. Monitor Changes Internally by Inotify/Fsnotify
97
-   Addition to above, in the "actual operation" (step 4) aufs re-lookup
98
-   the dentry on the branch, and returns EBUSY if it finds different
99
-   dentry.
100
-   Additionally, aufs sets the inotify/fsnotify watch for every dir on branches
101
-   during it is in cache. When the event is notified, aufs registers a
102
-   function to kernel 'events' thread by schedule_work(). And the
103
-   function sets some special status to the cached aufs dentry and inode
104
-   private data. If they are not cached, then aufs has nothing to
105
-   do. When the same file is accessed through aufs (step 0-3) later,
106
-   aufs will detect the status and refresh all necessary data.
107
-   In this mode, aufs has to ignore the event which is fired by aufs
108
-   itself.
109
-3. No Extra Validation
110
-   This is the simplest test and doesn't add any additional revalidation
111
-   test, and skip the revalidation in step 4. It is useful and improves
112
-   aufs performance when system surely hide the aufs branches from user,
113
-   by over-mounting something (or another method).

+ 0 - 74
Documentation/filesystems/aufs/design/04branch.txt

@@ -1,74 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Branch Manipulation
18
-
19
-Since aufs supports dynamic branch manipulation, ie. add/remove a branch
20
-and changing its permission/attribute, there are a lot of works to do.
21
-
22
-
23
-Add a Branch
24
-----------------------------------------------------------------------
25
-o Confirm the adding dir exists outside of aufs, including loopback
26
-  mount, and its various attributes.
27
-o Initialize the xino file and whiteout bases if necessary.
28
-  See struct.txt.
29
-
30
-o Check the owner/group/mode of the directory
31
-  When the owner/group/mode of the adding directory differs from the
32
-  existing branch, aufs issues a warning because it may impose a
33
-  security risk.
34
-  For example, when a upper writable branch has a world writable empty
35
-  top directory, a malicious user can create any files on the writable
36
-  branch directly, like copy-up and modify manually. If something like
37
-  /etc/{passwd,shadow} exists on the lower readonly branch but the upper
38
-  writable branch, and the writable branch is world-writable, then a
39
-  malicious guy may create /etc/passwd on the writable branch directly
40
-  and the infected file will be valid in aufs.
41
-  I am afraid it can be a security issue, but aufs can do nothing except
42
-  producing a warning.
43
-
44
-
45
-Delete a Branch
46
-----------------------------------------------------------------------
47
-o Confirm the deleting branch is not busy
48
-  To be general, there is one merit to adopt "remount" interface to
49
-  manipulate branches. It is to discard caches. At deleting a branch,
50
-  aufs checks the still cached (and connected) dentries and inodes. If
51
-  there are any, then they are all in-use. An inode without its
52
-  corresponding dentry can be alive alone (for example, inotify/fsnotify case).
53
-
54
-  For the cached one, aufs checks whether the same named entry exists on
55
-  other branches.
56
-  If the cached one is a directory, because aufs provides a merged view
57
-  to users, as long as one dir is left on any branch aufs can show the
58
-  dir to users. In this case, the branch can be removed from aufs.
59
-  Otherwise aufs rejects deleting the branch.
60
-
61
-  If any file on the deleting branch is opened by aufs, then aufs
62
-  rejects deleting.
63
-
64
-
65
-Modify the Permission of a Branch
66
-----------------------------------------------------------------------
67
-o Re-initialize or remove the xino file and whiteout bases if necessary.
68
-  See struct.txt.
69
-
70
-o rw --> ro: Confirm the modifying branch is not busy
71
-  Aufs rejects the request if any of these conditions are true.
72
-  - a file on the branch is mmap-ed.
73
-  - a regular file on the branch is opened for write and there is no
74
-    same named entry on the upper branch.

+ 0 - 64
Documentation/filesystems/aufs/design/05wbr_policy.txt

@@ -1,64 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Policies to Select One among Multiple Writable Branches
18
-----------------------------------------------------------------------
19
-When the number of writable branch is more than one, aufs has to decide
20
-the target branch for file creation or copy-up. By default, the highest
21
-writable branch which has the parent (or ancestor) dir of the target
22
-file is chosen (top-down-parent policy).
23
-By user's request, aufs implements some other policies to select the
24
-writable branch, for file creation several policies, round-robin,
25
-most-free-space, and other policies. For copy-up, top-down-parent,
26
-bottom-up-parent, bottom-up and others.
27
-
28
-As expected, the round-robin policy selects the branch in circular. When
29
-you have two writable branches and creates 10 new files, 5 files will be
30
-created for each branch. mkdir(2) systemcall is an exception. When you
31
-create 10 new directories, all will be created on the same branch.
32
-And the most-free-space policy selects the one which has most free
33
-space among the writable branches. The amount of free space will be
34
-checked by aufs internally, and users can specify its time interval.
35
-
36
-The policies for copy-up is more simple,
37
-top-down-parent is equivalent to the same named on in create policy,
38
-bottom-up-parent selects the writable branch where the parent dir
39
-exists and the nearest upper one from the copyup-source,
40
-bottom-up selects the nearest upper writable branch from the
41
-copyup-source, regardless the existence of the parent dir.
42
-
43
-There are some rules or exceptions to apply these policies.
44
-- If there is a readonly branch above the policy-selected branch and
45
-  the parent dir is marked as opaque (a variation of whiteout), or the
46
-  target (creating) file is whiteout-ed on the upper readonly branch,
47
-  then the result of the policy is ignored and the target file will be
48
-  created on the nearest upper writable branch than the readonly branch.
49
-- If there is a writable branch above the policy-selected branch and
50
-  the parent dir is marked as opaque or the target file is whiteouted
51
-  on the branch, then the result of the policy is ignored and the target
52
-  file will be created on the highest one among the upper writable
53
-  branches who has diropq or whiteout. In case of whiteout, aufs removes
54
-  it as usual.
55
-- link(2) and rename(2) systemcalls are exceptions in every policy.
56
-  They try selecting the branch where the source exists as possible
57
-  since copyup a large file will take long time. If it can't be,
58
-  ie. the branch where the source exists is readonly, then they will
59
-  follow the copyup policy.
60
-- There is an exception for rename(2) when the target exists.
61
-  If the rename target exists, aufs compares the index of the branches
62
-  where the source and the target exists and selects the higher
63
-  one. If the selected branch is readonly, then aufs follows the
64
-  copyup policy.

+ 0 - 120
Documentation/filesystems/aufs/design/06fhsm.txt

@@ -1,120 +0,0 @@
1
-
2
-# Copyright (C) 2011-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program; if not, write to the Free Software
16
-# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
17
-
18
-
19
-File-based Hierarchical Storage Management (FHSM)
20
-----------------------------------------------------------------------
21
-Hierarchical Storage Management (or HSM) is a well-known feature in the
22
-storage world. Aufs provides this feature as file-based with multiple
23
-writable branches, based upon the principle of "Colder, the Lower".
24
-Here the word "colder" means that the less used files, and "lower" means
25
-that the position in the order of the stacked branches vertically.
26
-These multiple writable branches are prioritized, ie. the topmost one
27
-should be the fastest drive and be used heavily.
28
-
29
-o Characters in aufs FHSM story
30
-- aufs itself and a new branch attribute.
31
-- a new ioctl interface to move-down and to establish a connection with
32
-  the daemon ("move-down" is a converse of "copy-up").
33
-- userspace tool and daemon.
34
-
35
-The userspace daemon establishes a connection with aufs and waits for
36
-the notification. The notified information is very similar to struct
37
-statfs containing the number of consumed blocks and inodes.
38
-When the consumed blocks/inodes of a branch exceeds the user-specified
39
-upper watermark, the daemon activates its move-down process until the
40
-consumed blocks/inodes reaches the user-specified lower watermark.
41
-
42
-The actual move-down is done by aufs based upon the request from
43
-user-space since we need to maintain the inode number and the internal
44
-pointer arrays in aufs.
45
-
46
-Currently aufs FHSM handles the regular files only. Additionally they
47
-must not be hard-linked nor pseudo-linked.
48
-
49
-
50
-o Cowork of aufs and the user-space daemon
51
-  During the userspace daemon established the connection, aufs sends a
52
-  small notification to it whenever aufs writes something into the
53
-  writable branch. But it may cost high since aufs issues statfs(2)
54
-  internally. So user can specify a new option to cache the
55
-  info. Actually the notification is controlled by these factors.
56
-  + the specified cache time.
57
-  + classified as "force" by aufs internally.
58
-  Until the specified time expires, aufs doesn't send the info
59
-  except the forced cases. When aufs decide forcing, the info is always
60
-  notified to userspace.
61
-  For example, the number of free inodes is generally large enough and
62
-  the shortage of it happens rarely. So aufs doesn't force the
63
-  notification when creating a new file, directory and others. This is
64
-  the typical case which aufs doesn't force.
65
-  When aufs writes the actual filedata and the files consumes any of new
66
-  blocks, the aufs forces notifying.
67
-
68
-
69
-o Interfaces in aufs
70
-- New branch attribute.
71
-  + fhsm
72
-    Specifies that the branch is managed by FHSM feature. In other word,
73
-    participant in the FHSM.
74
-    When nofhsm is set to the branch, it will not be the source/target
75
-    branch of the move-down operation. This attribute is set
76
-    independently from coo and moo attributes, and if you want full
77
-    FHSM, you should specify them as well.
78
-- New mount option.
79
-  + fhsm_sec
80
-    Specifies a second to suppress many less important info to be
81
-    notified.
82
-- New ioctl.
83
-  + AUFS_CTL_FHSM_FD
84
-    create a new file descriptor which userspace can read the notification
85
-    (a subset of struct statfs) from aufs.
86
-- Module parameter 'brs'
87
-  It has to be set to 1. Otherwise the new mount option 'fhsm' will not
88
-  be set.
89
-- mount helpers /sbin/mount.aufs and /sbin/umount.aufs
90
-  When there are two or more branches with fhsm attributes,
91
-  /sbin/mount.aufs invokes the user-space daemon and /sbin/umount.aufs
92
-  terminates it. As a result of remounting and branch-manipulation, the
93
-  number of branches with fhsm attribute can be one. In this case,
94
-  /sbin/mount.aufs will terminate the user-space daemon.
95
-
96
-
97
-Finally the operation is done as these steps in kernel-space.
98
-- make sure that,
99
-  + no one else is using the file.
100
-  + the file is not hard-linked.
101
-  + the file is not pseudo-linked.
102
-  + the file is a regular file.
103
-  + the parent dir is not opaqued.
104
-- find the target writable branch.
105
-- make sure the file is not whiteout-ed by the upper (than the target)
106
-  branch.
107
-- make the parent dir on the target branch.
108
-- mutex lock the inode on the branch.
109
-- unlink the whiteout on the target branch (if exists).
110
-- lookup and create the whiteout-ed temporary name on the target branch.
111
-- copy the file as the whiteout-ed temporary name on the target branch.
112
-- rename the whiteout-ed temporary name to the original name.
113
-- unlink the file on the source branch.
114
-- maintain the internal pointer array and the external inode number
115
-  table (XINO).
116
-- maintain the timestamps and other attributes of the parent dir and the
117
-  file.
118
-
119
-And of course, in every step, an error may happen. So the operation
120
-should restore the original file state after an error happens.

+ 0 - 72
Documentation/filesystems/aufs/design/06mmap.txt

@@ -1,72 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-mmap(2) -- File Memory Mapping
18
-----------------------------------------------------------------------
19
-In aufs, the file-mapped pages are handled by a branch fs directly, no
20
-interaction with aufs. It means aufs_mmap() calls the branch fs's
21
-->mmap().
22
-This approach is simple and good, but there is one problem.
23
-Under /proc, several entries show the mmapped files by its path (with
24
-device and inode number), and the printed path will be the path on the
25
-branch fs's instead of virtual aufs's.
26
-This is not a problem in most cases, but some utilities lsof(1) (and its
27
-user) may expect the path on aufs.
28
-
29
-To address this issue, aufs adds a new member called vm_prfile in struct
30
-vm_area_struct (and struct vm_region). The original vm_file points to
31
-the file on the branch fs in order to handle everything correctly as
32
-usual. The new vm_prfile points to a virtual file in aufs, and the
33
-show-functions in procfs refers to vm_prfile if it is set.
34
-Also we need to maintain several other places where touching vm_file
35
-such like
36
-- fork()/clone() copies vma and the reference count of vm_file is
37
-  incremented.
38
-- merging vma maintains the ref count too.
39
-
40
-This is not a good approach. It just fakes the printed path. But it
41
-leaves all behaviour around f_mapping unchanged. This is surely an
42
-advantage.
43
-Actually aufs had adopted another complicated approach which calls
44
-generic_file_mmap() and handles struct vm_operations_struct. In this
45
-approach, aufs met a hard problem and I could not solve it without
46
-switching the approach.
47
-
48
-There may be one more another approach which is
49
-- bind-mount the branch-root onto the aufs-root internally
50
-- grab the new vfsmount (ie. struct mount)
51
-- lazy-umount the branch-root internally
52
-- in open(2) the aufs-file, open the branch-file with the hidden
53
-  vfsmount (instead of the original branch's vfsmount)
54
-- ideally this "bind-mount and lazy-umount" should be done atomically,
55
-  but it may be possible from userspace by the mount helper.
56
-
57
-Adding the internal hidden vfsmount and using it in opening a file, the
58
-file path under /proc will be printed correctly. This approach looks
59
-smarter, but is not possible I am afraid.
60
-- aufs-root may be bind-mount later. when it happens, another hidden
61
-  vfsmount will be required.
62
-- it is hard to get the chance to bind-mount and lazy-umount
63
-  + in kernel-space, FS can have vfsmount in open(2) via
64
-    file->f_path, and aufs can know its vfsmount. But several locks are
65
-    already acquired, and if aufs tries to bind-mount and lazy-umount
66
-    here, then it may cause a deadlock.
67
-  + in user-space, bind-mount doesn't invoke the mount helper.
68
-- since /proc shows dev and ino, aufs has to give vma these info. it
69
-  means a new member vm_prinode will be necessary. this is essentially
70
-  equivalent to vm_prfile described above.
71
-
72
-I have to give up this "looks-smater" approach.

+ 0 - 96
Documentation/filesystems/aufs/design/06xattr.txt

@@ -1,96 +0,0 @@
1
-
2
-# Copyright (C) 2014-2017 Junjiro R. Okajima
3
-#
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-#
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-#
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program; if not, write to the Free Software
16
-# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
17
-
18
-
19
-Listing XATTR/EA and getting the value
20
-----------------------------------------------------------------------
21
-For the inode standard attributes (owner, group, timestamps, etc.), aufs
22
-shows the values from the topmost existing file. This behaviour is good
23
-for the non-dir entries since the bahaviour exactly matches the shown
24
-information. But for the directories, aufs considers all the same named
25
-entries on the lower branches. Which means, if one of the lower entry
26
-rejects readdir call, then aufs returns an error even if the topmost
27
-entry allows it. This behaviour is necessary to respect the branch fs's
28
-security, but can make users confused since the user-visible standard
29
-attributes don't match the behaviour.
30
-To address this issue, aufs has a mount option called dirperm1 which
31
-checks the permission for the topmost entry only, and ignores the lower
32
-entry's permission.
33
-
34
-A similar issue can happen around XATTR.
35
-getxattr(2) and listxattr(2) families behave as if dirperm1 option is
36
-always set. Otherwise these very unpleasant situation would happen.
37
-- listxattr(2) may return the duplicated entries.
38
-- users may not be able to remove or reset the XATTR forever,
39
-
40
-
41
-XATTR/EA support in the internal (copy,move)-(up,down)
42
-----------------------------------------------------------------------
43
-Generally the extended attributes of inode are categorized as these.
44
-- "security" for LSM and capability.
45
-- "system" for posix ACL, 'acl' mount option is required for the branch
46
-  fs generally.
47
-- "trusted" for userspace, CAP_SYS_ADMIN is required.
48
-- "user" for userspace, 'user_xattr' mount option is required for the
49
-  branch fs generally.
50
-
51
-Moreover there are some other categories. Aufs handles these rather
52
-unpopular categories as the ordinary ones, ie. there is no special
53
-condition nor exception.
54
-
55
-In copy-up, the support for XATTR on the dst branch may differ from the
56
-src branch. In this case, the copy-up operation will get an error and
57
-the original user operation which triggered the copy-up will fail. It
58
-can happen that even all copy-up will fail.
59
-When both of src and dst branches support XATTR and if an error occurs
60
-during copying XATTR, then the copy-up should fail obviously. That is a
61
-good reason and aufs should return an error to userspace. But when only
62
-the src branch support that XATTR, aufs should not return an error.
63
-For example, the src branch supports ACL but the dst branch doesn't
64
-because the dst branch may natively un-support it or temporary
65
-un-support it due to "noacl" mount option. Of course, the dst branch fs
66
-may NOT return an error even if the XATTR is not supported. It is
67
-totally up to the branch fs.
68
-
69
-Anyway when the aufs internal copy-up gets an error from the dst branch
70
-fs, then aufs tries removing the just copied entry and returns the error
71
-to the userspace. The worst case of this situation will be all copy-up
72
-will fail.
73
-
74
-For the copy-up operation, there two basic approaches.
75
-- copy the specified XATTR only (by category above), and return the
76
-  error unconditionally if it happens.
77
-- copy all XATTR, and ignore the error on the specified category only.
78
-
79
-In order to support XATTR and to implement the correct behaviour, aufs
80
-chooses the latter approach and introduces some new branch attributes,
81
-"icexsec", "icexsys", "icextr", "icexusr", and "icexoth".
82
-They correspond to the XATTR namespaces (see above). Additionally, to be
83
-convenient, "icex" is also provided which means all "icex*" attributes
84
-are set (here the word "icex" stands for "ignore copy-error on XATTR").
85
-
86
-The meaning of these attributes is to ignore the error from setting
87
-XATTR on that branch.
88
-Note that aufs tries copying all XATTR unconditionally, and ignores the
89
-error from the dst branch according to the specified attributes.
90
-
91
-Some XATTR may have its default value. The default value may come from
92
-the parent dir or the environment. If the default value is set at the
93
-file creating-time, it will be overwritten by copy-up.
94
-Some contradiction may happen I am afraid.
95
-Do we need another attribute to stop copying XATTR? I am unsure. For
96
-now, aufs implements the branch attributes to ignore the error.

+ 0 - 58
Documentation/filesystems/aufs/design/07export.txt

@@ -1,58 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Export Aufs via NFS
18
-----------------------------------------------------------------------
19
-Here is an approach.
20
-- like xino/xib, add a new file 'xigen' which stores aufs inode
21
-  generation.
22
-- iget_locked(): initialize aufs inode generation for a new inode, and
23
-  store it in xigen file.
24
-- destroy_inode(): increment aufs inode generation and store it in xigen
25
-  file. it is necessary even if it is not unlinked, because any data of
26
-  inode may be changed by UDBA.
27
-- encode_fh(): for a root dir, simply return FILEID_ROOT. otherwise
28
-  build file handle by
29
-  + branch id (4 bytes)
30
-  + superblock generation (4 bytes)
31
-  + inode number (4 or 8 bytes)
32
-  + parent dir inode number (4 or 8 bytes)
33
-  + inode generation (4 bytes))
34
-  + return value of exportfs_encode_fh() for the parent on a branch (4
35
-    bytes)
36
-  + file handle for a branch (by exportfs_encode_fh())
37
-- fh_to_dentry():
38
-  + find the index of a branch from its id in handle, and check it is
39
-    still exist in aufs.
40
-  + 1st level: get the inode number from handle and search it in cache.
41
-  + 2nd level: if not found in cache, get the parent inode number from
42
-    the handle and search it in cache. and then open the found parent
43
-    dir, find the matching inode number by vfs_readdir() and get its
44
-    name, and call lookup_one_len() for the target dentry.
45
-  + 3rd level: if the parent dir is not cached, call
46
-    exportfs_decode_fh() for a branch and get the parent on a branch,
47
-    build a pathname of it, convert it a pathname in aufs, call
48
-    path_lookup(). now aufs gets a parent dir dentry, then handle it as
49
-    the 2nd level.
50
-  + to open the dir, aufs needs struct vfsmount. aufs keeps vfsmount
51
-    for every branch, but not itself. to get this, (currently) aufs
52
-    searches in current->nsproxy->mnt_ns list. it may not be a good
53
-    idea, but I didn't get other approach.
54
-  + test the generation of the gotten inode.
55
-- every inode operation: they may get EBUSY due to UDBA. in this case,
56
-  convert it into ESTALE for NFSD.
57
-- readdir(): call lockdep_on/off() because filldir in NFSD calls
58
-  lookup_one_len(), vfs_getattr(), encode_fh() and others.

+ 0 - 52
Documentation/filesystems/aufs/design/08shwh.txt

@@ -1,52 +0,0 @@
1
-
2
-# Copyright (C) 2005-2017 Junjiro R. Okajima
3
-# 
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-# 
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-# 
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Show Whiteout Mode (shwh)
18
-----------------------------------------------------------------------
19
-Generally aufs hides the name of whiteouts. But in some cases, to show
20
-them is very useful for users. For instance, creating a new middle layer
21
-(branch) by merging existing layers.
22
-
23
-(borrowing aufs1 HOW-TO from a user, Michael Towers)
24
-When you have three branches,
25
-- Bottom: 'system', squashfs (underlying base system), read-only
26
-- Middle: 'mods', squashfs, read-only
27
-- Top: 'overlay', ram (tmpfs), read-write
28
-
29
-The top layer is loaded at boot time and saved at shutdown, to preserve
30
-the changes made to the system during the session.
31
-When larger changes have been made, or smaller changes have accumulated,
32
-the size of the saved top layer data grows. At this point, it would be
33
-nice to be able to merge the two overlay branches ('mods' and 'overlay')
34
-and rewrite the 'mods' squashfs, clearing the top layer and thus
35
-restoring save and load speed.
36
-
37
-This merging is simplified by the use of another aufs mount, of just the
38
-two overlay branches using the 'shwh' option.
39
-# mount -t aufs -o ro,shwh,br:/livesys/overlay=ro+wh:/livesys/mods=rr+wh \
40
-	aufs /livesys/merge_union
41
-
42
-A merged view of these two branches is then available at
43
-/livesys/merge_union, and the new feature is that the whiteouts are
44
-visible!
45
-Note that in 'shwh' mode the aufs mount must be 'ro', which will disable
46
-writing to all branches. Also the default mode for all branches is 'ro'.
47
-It is now possible to save the combined contents of the two overlay
48
-branches to a new squashfs, e.g.:
49
-# mksquashfs /livesys/merge_union /path/to/newmods.squash
50
-
51
-This new squashfs archive can be stored on the boot device and the
52
-initramfs will use it to replace the old one at the next boot.

+ 0 - 47
Documentation/filesystems/aufs/design/10dynop.txt

@@ -1,47 +0,0 @@
1
-
2
-# Copyright (C) 2010-2017 Junjiro R. Okajima
3
-#
4
-# This program is free software; you can redistribute it and/or modify
5
-# it under the terms of the GNU General Public License as published by
6
-# the Free Software Foundation; either version 2 of the License, or
7
-# (at your option) any later version.
8
-#
9
-# This program is distributed in the hope that it will be useful,
10
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
11
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
12
-# GNU General Public License for more details.
13
-#
14
-# You should have received a copy of the GNU General Public License
15
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
16
-
17
-Dynamically customizable FS operations
18
-----------------------------------------------------------------------
19
-Generally FS operations (struct inode_operations, struct
20
-address_space_operations, struct file_operations, etc.) are defined as
21
-"static const", but it never means that FS have only one set of
22
-operation. Some FS have multiple sets of them. For instance, ext2 has
23
-three sets, one for XIP, for NOBH, and for normal.
24
-Since aufs overrides and redirects these operations, sometimes aufs has
25
-to change its behaviour according to the branch FS type. More importantly
26
-VFS acts differently if a function (member in the struct) is set or
27
-not. It means aufs should have several sets of operations and select one
28
-among them according to the branch FS definition.
29
-
30
-In order to solve this problem and not to affect the behaviour of VFS,
31
-aufs defines these operations dynamically. For instance, aufs defines
32
-dummy direct_IO function for struct address_space_operations, but it may
33
-not be set to the address_space_operations actually. When the branch FS
34
-doesn't have it, aufs doesn't set it to its address_space_operations
35
-while the function definition itself is still alive. So the behaviour
36
-itself will not change, and it will return an error when direct_IO is
37
-not set.
38
-
39
-The lifetime of these dynamically generated operation object is
40
-maintained by aufs branch object. When the branch is removed from aufs,
41
-the reference counter of the object is decremented. When it reaches
42
-zero, the dynamically generated operation object will be freed.
43
-
44
-This approach is designed to support AIO (io_submit), Direct I/O and
45
-XIP (DAX) mainly.
46
-Currently this approach is applied to address_space_operations for
47
-regular files only.

+ 4 - 0
Documentation/kernel-parameters.txt

@@ -1255,6 +1255,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
1255 1255
 			When zero, profiling data is discarded and associated
1256 1256
 			debugfs files are removed at module unload time.
1257 1257
 
1258
+	goldfish	[X86] Enable the goldfish android emulator platform.
1259
+			Don't use this when you are not running on the
1260
+			android emulator
1261
+
1258 1262
 	gpt		[EFI] Forces disk with valid GPT signature but
1259 1263
 			invalid Protective MBR to be treated as GPT. If the
1260 1264
 			primary GPT is corrupted, it enables the backup/alternate

+ 0 - 13
MAINTAINERS

@@ -2029,19 +2029,6 @@ F:	include/linux/audit.h
2029 2029
 F:	include/uapi/linux/audit.h
2030 2030
 F:	kernel/audit*
2031 2031
 
2032
-AUFS (advanced multi layered unification filesystem) FILESYSTEM
2033
-M: "J. R. Okajima" <hooanon05g@gmail.com>
2034
-L: linux-unionfs@vger.kernel.org
2035
-L: aufs-users@lists.sourceforge.net (members only)
2036
-W: http://aufs.sourceforge.net
2037
-T: git://github.com/sfjro/aufs4-linux.git
2038
-S: Supported
2039
-F: Documentation/filesystems/aufs/
2040
-F: Documentation/ABI/testing/debugfs-aufs
2041
-F: Documentation/ABI/testing/sysfs-aufs
2042
-F: fs/aufs/
2043
-F: include/uapi/linux/aufs_type.h
2044
-
2045 2032
 AUXILIARY DISPLAY DRIVERS
2046 2033
 M:	Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com>
2047 2034
 W:	http://miguelojeda.es/auxdisplay.htm

+ 1 - 1
Makefile

@@ -1,6 +1,6 @@
1 1
 VERSION = 4
2 2
 PATCHLEVEL = 4
3
-SUBLEVEL = 45
3
+SUBLEVEL = 52
4 4
 EXTRAVERSION = -gnu
5 5
 NAME = Blurry Fish Butt
6 6
 

+ 0 - 4
README-heads

@@ -1,4 +0,0 @@
1
-current git master is kernel 4.4.45
2
-	* patched with grsecurity
3
-	* patched with aufs4
4
-	* deblobbed with linux-libre

+ 3 - 1
arch/arc/include/asm/delay.h

@@ -26,7 +26,9 @@ static inline void __delay(unsigned long loops)
26 26
 	"	lp  1f			\n"
27 27
 	"	nop			\n"
28 28
 	"1:				\n"
29
-	: : "r"(loops));
29
+	:
30
+        : "r"(loops)
31
+        : "lp_count");
30 32
 }
31 33
 
32 34
 extern void __bad_udelay(void);

+ 2 - 1
arch/arc/kernel/unaligned.c

@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long address, struct pt_regs *regs,
241 241
 	if (state.fault)
242 242
 		goto fault;
243 243
 
244
+	/* clear any remanants of delay slot */
244 245
 	if (delay_mode(regs)) {
245
-		regs->ret = regs->bta;
246
+		regs->ret = regs->bta & ~1U;
246 247
 		regs->status32 &= ~STATUS_DE_MASK;
247 248
 	} else {
248 249
 		regs->ret += state.instr_len;

+ 1 - 1
arch/arm/kernel/ptrace.c

@@ -600,7 +600,7 @@ static int gpr_set(struct task_struct *target,
600 600
 		   const void *kbuf, const void __user *ubuf)
601 601
 {
602 602
 	int ret;
603
-	struct pt_regs newregs;
603
+	struct pt_regs newregs = *task_pt_regs(target);
604 604
 
605 605
 	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
606 606
 				 &newregs,

+ 1 - 1
arch/arm/lib/getuser.S

@@ -67,7 +67,7 @@ ENTRY(__get_user_4)
67 67
 ENDPROC(__get_user_4)
68 68
 
69 69
 ENTRY(__get_user_8)
70
-	check_uaccess r0, 8, r1, r2, __get_user_bad
70
+	check_uaccess r0, 8, r1, r2, __get_user_bad8
71 71
 #ifdef CONFIG_THUMB2_KERNEL
72 72
 5: TUSER(ldr)	r2, [r0]
73 73
 6: TUSER(ldr)	r3, [r0, #4]

+ 2 - 2
arch/arm/mm/fault.c

@@ -772,9 +772,9 @@ static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
772 772
 
773 773
 void __init early_abt_enable(void)
774 774
 {
775
-	fsr_info[22].fn = early_abort_handler;
775
+	fsr_info[FSR_FS_AEA].fn = early_abort_handler;
776 776
 	local_abt_enable();
777
-	fsr_info[22].fn = do_bad;
777
+	fsr_info[FSR_FS_AEA].fn = do_bad;
778 778
 }
779 779
 
780 780
 #ifndef CONFIG_ARM_LPAE

+ 4 - 0
arch/arm/mm/fault.h

@@ -12,11 +12,15 @@
12 12
 #define FSR_FS5_0		(0x3f)
13 13
 
14 14
 #ifdef CONFIG_ARM_LPAE
15
+#define FSR_FS_AEA		17
16
+
15 17
 static inline int fsr_fs(unsigned int fsr)
16 18
 {
17 19
 	return fsr & FSR_FS5_0;
18 20
 }
19 21
 #else
22
+#define FSR_FS_AEA		22
23
+
20 24
 static inline int fsr_fs(unsigned int fsr)
21 25
 {
22 26
 	return (fsr & FSR_FS3_0) | (fsr & FSR_FS4) >> 6;

+ 42 - 46
arch/arm64/crypto/aes-modes.S

@@ -193,15 +193,16 @@ AES_ENTRY(aes_cbc_encrypt)
193 193
 	cbz		w6, .Lcbcencloop
194 194
 
195 195
 	ld1		{v0.16b}, [x5]			/* get iv */
196
-	enc_prepare	w3, x2, x5
196
+	enc_prepare	w3, x2, x6
197 197
 
198 198
 .Lcbcencloop:
199 199
 	ld1		{v1.16b}, [x1], #16		/* get next pt block */
200 200
 	eor		v0.16b, v0.16b, v1.16b		/* ..and xor with iv */
201
-	encrypt_block	v0, w3, x2, x5, w6
201
+	encrypt_block	v0, w3, x2, x6, w7
202 202
 	st1		{v0.16b}, [x0], #16
203 203
 	subs		w4, w4, #1
204 204
 	bne		.Lcbcencloop
205
+	st1		{v0.16b}, [x5]			/* return iv */
205 206
 	ret
206 207
 AES_ENDPROC(aes_cbc_encrypt)
207 208
 
@@ -211,7 +212,7 @@ AES_ENTRY(aes_cbc_decrypt)
211 212
 	cbz		w6, .LcbcdecloopNx
212 213
 
213 214
 	ld1		{v7.16b}, [x5]			/* get iv */
214
-	dec_prepare	w3, x2, x5
215
+	dec_prepare	w3, x2, x6
215 216
 
216 217
 .LcbcdecloopNx:
217 218
 #if INTERLEAVE >= 2
@@ -248,7 +249,7 @@ AES_ENTRY(aes_cbc_decrypt)
248 249
 .Lcbcdecloop:
249 250
 	ld1		{v1.16b}, [x1], #16		/* get next ct block */
250 251
 	mov		v0.16b, v1.16b			/* ...and copy to v0 */
251
-	decrypt_block	v0, w3, x2, x5, w6
252
+	decrypt_block	v0, w3, x2, x6, w7
252 253
 	eor		v0.16b, v0.16b, v7.16b		/* xor with iv => pt */
253 254
 	mov		v7.16b, v1.16b			/* ct is next iv */
254 255
 	st1		{v0.16b}, [x0], #16
@@ -256,6 +257,7 @@ AES_ENTRY(aes_cbc_decrypt)
256 257
 	bne		.Lcbcdecloop
257 258
 .Lcbcdecout:
258 259
 	FRAME_POP
260
+	st1		{v7.16b}, [x5]			/* return iv */
259 261
 	ret
260 262
 AES_ENDPROC(aes_cbc_decrypt)
261 263
 
@@ -267,24 +269,15 @@ AES_ENDPROC(aes_cbc_decrypt)
267 269
 
268 270
 AES_ENTRY(aes_ctr_encrypt)
269 271
 	FRAME_PUSH
270
-	cbnz		w6, .Lctrfirst		/* 1st time around? */
271
-	umov		x5, v4.d[1]		/* keep swabbed ctr in reg */
272
-	rev		x5, x5
273
-#if INTERLEAVE >= 2
274
-	cmn		w5, w4			/* 32 bit overflow? */
275
-	bcs		.Lctrinc
276
-	add		x5, x5, #1		/* increment BE ctr */
277
-	b		.LctrincNx
278
-#else
279
-	b		.Lctrinc
280
-#endif
281
-.Lctrfirst:
272
+	cbz		w6, .Lctrnotfirst	/* 1st time around? */
282 273
 	enc_prepare	w3, x2, x6
283 274
 	ld1		{v4.16b}, [x5]
284
-	umov		x5, v4.d[1]		/* keep swabbed ctr in reg */
285
-	rev		x5, x5
275
+
276
+.Lctrnotfirst:
277
+	umov		x8, v4.d[1]		/* keep swabbed ctr in reg */
278
+	rev		x8, x8
286 279
 #if INTERLEAVE >= 2
287
-	cmn		w5, w4			/* 32 bit overflow? */
280
+	cmn		w8, w4			/* 32 bit overflow? */
288 281
 	bcs		.Lctrloop
289 282
 .LctrloopNx:
290 283
 	subs		w4, w4, #INTERLEAVE
@@ -292,11 +285,11 @@ AES_ENTRY(aes_ctr_encrypt)
292 285
 #if INTERLEAVE == 2
293 286
 	mov		v0.8b, v4.8b
294 287
 	mov		v1.8b, v4.8b
295
-	rev		x7, x5
296
-	add		x5, x5, #1
288
+	rev		x7, x8
289
+	add		x8, x8, #1
297 290
 	ins		v0.d[1], x7
298
-	rev		x7, x5
299
-	add		x5, x5, #1
291
+	rev		x7, x8
292
+	add		x8, x8, #1
300 293
 	ins		v1.d[1], x7
301 294
 	ld1		{v2.16b-v3.16b}, [x1], #32	/* get 2 input blocks */
302 295
 	do_encrypt_block2x
@@ -305,7 +298,7 @@ AES_ENTRY(aes_ctr_encrypt)
305 298
 	st1		{v0.16b-v1.16b}, [x0], #32
306 299
 #else
307 300
 	ldr		q8, =0x30000000200000001	/* addends 1,2,3[,0] */
308
-	dup		v7.4s, w5
301
+	dup		v7.4s, w8
309 302
 	mov		v0.16b, v4.16b
310 303
 	add		v7.4s, v7.4s, v8.4s
311 304
 	mov		v1.16b, v4.16b
@@ -323,18 +316,12 @@ AES_ENTRY(aes_ctr_encrypt)
323 316
 	eor		v2.16b, v7.16b, v2.16b
324 317
 	eor		v3.16b, v5.16b, v3.16b
325 318
 	st1		{v0.16b-v3.16b}, [x0], #64
326
-	add		x5, x5, #INTERLEAVE
319
+	add		x8, x8, #INTERLEAVE
327 320
 #endif
328
-	cbz		w4, .LctroutNx
329
-.LctrincNx:
330
-	rev		x7, x5
321
+	rev		x7, x8
331 322
 	ins		v4.d[1], x7
323
+	cbz		w4, .Lctrout
332 324
 	b		.LctrloopNx
333
-.LctroutNx:
334
-	sub		x5, x5, #1
335
-	rev		x7, x5
336
-	ins		v4.d[1], x7
337
-	b		.Lctrout
338 325
 .Lctr1x:
339 326
 	adds		w4, w4, #INTERLEAVE
340 327
 	beq		.Lctrout
@@ -342,30 +329,39 @@ AES_ENTRY(aes_ctr_encrypt)
342 329
 .Lctrloop:
343 330
 	mov		v0.16b, v4.16b
344 331
 	encrypt_block	v0, w3, x2, x6, w7
332
+
333
+	adds		x8, x8, #1		/* increment BE ctr */
334
+	rev		x7, x8
335
+	ins		v4.d[1], x7
336
+	bcs		.Lctrcarry		/* overflow? */
337
+
338
+.Lctrcarrydone:
345 339
 	subs		w4, w4, #1
346 340
 	bmi		.Lctrhalfblock		/* blocks < 0 means 1/2 block */
347 341
 	ld1		{v3.16b}, [x1], #16
348 342
 	eor		v3.16b, v0.16b, v3.16b
349 343
 	st1		{v3.16b}, [x0], #16
350
-	beq		.Lctrout
351
-.Lctrinc:
352
-	adds		x5, x5, #1		/* increment BE ctr */
353
-	rev		x7, x5
354
-	ins		v4.d[1], x7
355
-	bcc		.Lctrloop		/* no overflow? */
356
-	umov		x7, v4.d[0]		/* load upper word of ctr  */
357
-	rev		x7, x7			/* ... to handle the carry */
358
-	add		x7, x7, #1
359
-	rev		x7, x7
360
-	ins		v4.d[0], x7
361
-	b		.Lctrloop
344
+	bne		.Lctrloop
345
+
346
+.Lctrout:
347
+	st1		{v4.16b}, [x5]		/* return next CTR value */
348
+	FRAME_POP
349
+	ret
350
+
362 351
 .Lctrhalfblock:
363 352
 	ld1		{v3.8b}, [x1]
364 353
 	eor		v3.8b, v0.8b, v3.8b
365 354
 	st1		{v3.8b}, [x0]
366
-.Lctrout:
367 355
 	FRAME_POP
368 356
 	ret
357
+
358
+.Lctrcarry:
359
+	umov		x7, v4.d[0]		/* load upper word of ctr  */
360
+	rev		x7, x7			/* ... to handle the carry */
361
+	add		x7, x7, #1
362
+	rev		x7, x7
363
+	ins		v4.d[0], x7
364
+	b		.Lctrcarrydone
369 365
 AES_ENDPROC(aes_ctr_encrypt)
370 366
 	.ltorg
371 367
 

+ 7 - 1
arch/parisc/include/asm/bitops.h

@@ -6,7 +6,7 @@
6 6
 #endif
7 7
 
8 8
 #include <linux/compiler.h>
9
-#include <asm/types.h>		/* for BITS_PER_LONG/SHIFT_PER_LONG */
9
+#include <asm/types.h>
10 10
 #include <asm/byteorder.h>
11 11
 #include <asm/barrier.h>
12 12
 #include <linux/atomic.h>
@@ -17,6 +17,12 @@
17 17
  * to include/asm-i386/bitops.h or kerneldoc
18 18
  */
19 19
 
20
+#if __BITS_PER_LONG == 64
21
+#define SHIFT_PER_LONG 6
22
+#else
23
+#define SHIFT_PER_LONG 5
24
+#endif
25
+
20 26
 #define CHOP_SHIFTCOUNT(x) (((unsigned long) (x)) & (BITS_PER_LONG - 1))
21 27
 
22 28
 

+ 0 - 2
arch/parisc/include/uapi/asm/bitsperlong.h

@@ -3,10 +3,8 @@
3 3
 
4 4
 #if defined(__LP64__)
5 5
 #define __BITS_PER_LONG 64
6
-#define SHIFT_PER_LONG 6
7 6
 #else
8 7
 #define __BITS_PER_LONG 32
9
-#define SHIFT_PER_LONG 5
10 8
 #endif
11 9
 
12 10
 #include <asm-generic/bitsperlong.h>

+ 3 - 2
arch/parisc/include/uapi/asm/swab.h

@@ -1,6 +1,7 @@
1 1
 #ifndef _PARISC_SWAB_H
2 2
 #define _PARISC_SWAB_H
3 3
 
4
+#include <asm/bitsperlong.h>
4 5
 #include <linux/types.h>
5 6
 #include <linux/compiler.h>
6 7
 
@@ -38,7 +39,7 @@ static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
38 39
 }
39 40
 #define __arch_swab32 __arch_swab32
40 41
 
41
-#if BITS_PER_LONG > 32
42
+#if __BITS_PER_LONG > 32
42 43
 /*
43 44
 ** From "PA-RISC 2.0 Architecture", HP Professional Books.
44 45
 ** See Appendix I page 8 , "Endian Byte Swapping".
@@ -61,6 +62,6 @@ static inline __attribute_const__ __u64 __arch_swab64(__u64 x)
61 62
 	return x;
62 63
 }
63 64
 #define __arch_swab64 __arch_swab64
64
-#endif /* BITS_PER_LONG > 32 */
65
+#endif /* __BITS_PER_LONG > 32 */
65 66
 
66 67
 #endif /* _PARISC_SWAB_H */

+ 1 - 1
arch/powerpc/kernel/eeh_driver.c

@@ -485,7 +485,7 @@ static void *eeh_pe_detach_dev(void *data, void *userdata)
485 485
 static void *__eeh_clear_pe_frozen_state(void *data, void *flag)
486 486
 {
487 487
 	struct eeh_pe *pe = (struct eeh_pe *)data;
488
-	bool *clear_sw_state = flag;
488
+	bool clear_sw_state = *(bool *)flag;
489 489
 	int i, rc = 1;
490 490
 
491 491
 	for (i = 0; rc && i < 3; i++)

+ 3 - 0
arch/powerpc/kernel/prom_init.c

@@ -2664,6 +2664,9 @@ static void __init prom_find_boot_cpu(void)
2664 2664
 
2665 2665
 	cpu_pkg = call_prom("instance-to-package", 1, 1, prom_cpu);
2666 2666
 
2667
+	if (!PHANDLE_VALID(cpu_pkg))
2668
+		return;
2669
+
2667 2670
 	prom_getprop(cpu_pkg, "reg", &rval, sizeof(rval));
2668 2671
 	prom.cpu = be32_to_cpu(rval);
2669 2672
 

+ 8 - 0
arch/s390/kernel/ptrace.c

@@ -963,6 +963,11 @@ static int s390_fpregs_set(struct task_struct *target,
963 963
 	if (target == current)
964 964
 		save_fpu_regs();
965 965
 
966
+	if (MACHINE_HAS_VX)
967
+		convert_vx_to_fp(fprs, target->thread.fpu.vxrs);
968
+	else
969
+		memcpy(&fprs, target->thread.fpu.fprs, sizeof(fprs));
970
+
966 971
 	/* If setting FPC, must validate it first. */
967 972
 	if (count > 0 && pos < offsetof(s390_fp_regs, fprs)) {
968 973
 		u32 ufpc[2] = { target->thread.fpu.fpc, 0 };
@@ -1067,6 +1072,9 @@ static int s390_vxrs_low_set(struct task_struct *target,
1067 1072
 	if (target == current)
1068 1073
 		save_fpu_regs();
1069 1074
 
1075
+	for (i = 0; i < __NUM_VXRS_LOW; i++)
1076
+		vxrs[i] = *((__u64 *)(target->thread.fpu.vxrs + i) + 1);
1077
+
1070 1078
 	rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, vxrs, 0, -1);
1071 1079
 	if (rc == 0)
1072 1080
 		for (i = 0; i < __NUM_VXRS_LOW; i++)

+ 1 - 1
arch/tile/kernel/ptrace.c

@@ -111,7 +111,7 @@ static int tile_gpr_set(struct task_struct *target,
111 111
 			  const void *kbuf, const void __user *ubuf)
112 112
 {
113 113
 	int ret;
114
-	struct pt_regs regs;
114
+	struct pt_regs regs = *task_pt_regs(target);
115 115
 
116 116
 	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &regs, 0,
117 117
 				 sizeof(regs));

+ 2 - 2
arch/x86/kernel/apic/io_apic.c

@@ -1875,7 +1875,6 @@ static struct irq_chip ioapic_chip = {
1875 1875
 	.irq_ack		= irq_chip_ack_parent,
1876 1876
 	.irq_eoi		= ioapic_ack_level,
1877 1877
 	.irq_set_affinity	= ioapic_set_affinity,
1878
-	.irq_retrigger		= irq_chip_retrigger_hierarchy,
1879 1878
 	.flags			= IRQCHIP_SKIP_SET_WAKE,
1880 1879
 };
1881 1880
 
@@ -1887,7 +1886,6 @@ static struct irq_chip ioapic_ir_chip __read_mostly = {
1887 1886
 	.irq_ack		= irq_chip_ack_parent,
1888 1887
 	.irq_eoi		= ioapic_ir_ack_level,
1889 1888
 	.irq_set_affinity	= ioapic_set_affinity,
1890
-	.irq_retrigger		= irq_chip_retrigger_hierarchy,
1891 1889
 	.flags			= IRQCHIP_SKIP_SET_WAKE,
1892 1890
 };
1893 1891
 
@@ -2117,6 +2115,7 @@ static inline void __init check_timer(void)
2117 2115
 			if (idx != -1 && irq_trigger(idx))
2118 2116
 				unmask_ioapic_irq(irq_get_chip_data(0));
2119 2117
 		}
2118
+		irq_domain_deactivate_irq(irq_data);
2120 2119
 		irq_domain_activate_irq(irq_data);
2121 2120
 		if (timer_irq_works()) {
2122 2121
 			if (disable_timer_pin_1 > 0)
@@ -2138,6 +2137,7 @@ static inline void __init check_timer(void)
2138 2137
 		 * legacy devices should be connected to IO APIC #0
2139 2138
 		 */
2140 2139
 		replace_pin_at_irq_node(data, node, apic1, pin1, apic2, pin2);
2140
+		irq_domain_deactivate_irq(irq_data);
2141 2141
 		irq_domain_activate_irq(irq_data);
2142 2142
 		legacy_pic->unmask(0);
2143 2143
 		if (timer_irq_works()) {

+ 1 - 0
arch/x86/kernel/hpet.c

@@ -351,6 +351,7 @@ static int hpet_resume(struct clock_event_device *evt, int timer)
351 351
 	} else {
352 352
 		struct hpet_dev *hdev = EVT_TO_HPET_DEV(evt);
353 353
 
354
+		irq_domain_deactivate_irq(irq_get_irq_data(hdev->irq));
354 355
 		irq_domain_activate_irq(irq_get_irq_data(hdev->irq));
355 356
 		disable_irq(hdev->irq);
356 357
 		irq_set_affinity(hdev->irq, cpumask_of(hdev->cpu));

+ 24 - 32
arch/x86/kvm/vmx.c

@@ -4878,6 +4878,12 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
4878 4878
 	if (vmx_xsaves_supported())
4879 4879
 		vmcs_write64(XSS_EXIT_BITMAP, VMX_XSS_EXIT_BITMAP);
4880 4880
 
4881
+	if (enable_pml) {
4882
+		ASSERT(vmx->pml_pg);
4883
+		vmcs_write64(PML_ADDRESS, page_to_phys(vmx->pml_pg));
4884
+		vmcs_write16(GUEST_PML_INDEX, PML_ENTITY_NUM - 1);
4885
+	}
4886
+
4881 4887
 	return 0;
4882 4888
 }
4883 4889
 
@@ -7860,22 +7866,6 @@ static void vmx_get_exit_info(struct kvm_vcpu *vcpu, u64 *info1, u64 *info2)
7860 7866
 	*info2 = vmcs_read32(VM_EXIT_INTR_INFO);
7861 7867
 }
7862 7868
 
7863
-static int vmx_create_pml_buffer(struct vcpu_vmx *vmx)
7864
-{
7865
-	struct page *pml_pg;
7866
-
7867
-	pml_pg = alloc_page(GFP_KERNEL | __GFP_ZERO);
7868
-	if (!pml_pg)
7869
-		return -ENOMEM;
7870
-
7871
-	vmx->pml_pg = pml_pg;
7872
-
7873
-	vmcs_write64(PML_ADDRESS, page_to_phys(vmx->pml_pg));
7874
-	vmcs_write16(GUEST_PML_INDEX, PML_ENTITY_NUM - 1);
7875
-
7876
-	return 0;
7877
-}
7878
-
7879 7869
 static void vmx_destroy_pml_buffer(struct vcpu_vmx *vmx)
7880 7870
 {
7881 7871
 	if (vmx->pml_pg) {
@@ -8831,14 +8821,26 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
8831 8821
 	if (err)
8832 8822
 		goto free_vcpu;
8833 8823
 
8824
+	err = -ENOMEM;
8825
+
8826
+	/*
8827
+	 * If PML is turned on, failure on enabling PML just results in failure
8828
+	 * of creating the vcpu, therefore we can simplify PML logic (by
8829
+	 * avoiding dealing with cases, such as enabling PML partially on vcpus
8830
+	 * for the guest, etc.
8831
+	 */
8832
+	if (enable_pml) {
8833
+		vmx->pml_pg = alloc_page(GFP_KERNEL | __GFP_ZERO);
8834
+		if (!vmx->pml_pg)
8835
+			goto uninit_vcpu;
8836
+	}
8837
+
8834 8838
 	vmx->guest_msrs = kmalloc(PAGE_SIZE, GFP_KERNEL);
8835 8839
 	BUILD_BUG_ON(ARRAY_SIZE(vmx_msr_index) * sizeof(vmx->guest_msrs[0])
8836 8840
 		     > PAGE_SIZE);
8837 8841
 
8838
-	err = -ENOMEM;
8839
-	if (!vmx->guest_msrs) {
8840
-		goto uninit_vcpu;
8841
-	}
8842
+	if (!vmx->guest_msrs)
8843
+		goto free_pml;
8842 8844
 
8843 8845
 	vmx->loaded_vmcs = &vmx->vmcs01;
8844 8846
 	vmx->loaded_vmcs->vmcs = alloc_vmcs();
@@ -8882,18 +8884,6 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
8882 8884
 	vmx->nested.current_vmptr = -1ull;
8883 8885
 	vmx->nested.current_vmcs12 = NULL;
8884 8886
 
8885
-	/*
8886
-	 * If PML is turned on, failure on enabling PML just results in failure
8887
-	 * of creating the vcpu, therefore we can simplify PML logic (by
8888
-	 * avoiding dealing with cases, such as enabling PML partially on vcpus
8889
-	 * for the guest, etc.
8890
-	 */
8891
-	if (enable_pml) {
8892
-		err = vmx_create_pml_buffer(vmx);
8893
-		if (err)
8894
-			goto free_vmcs;
8895
-	}
8896
-
8897 8887
 	return &vmx->vcpu;
8898 8888
 
8899 8889
 free_vmcs:
@@ -8901,6 +8891,8 @@ free_vmcs:
8901 8891
 	free_loaded_vmcs(vmx->loaded_vmcs);
8902 8892
 free_msrs:
8903 8893
 	kfree(vmx->guest_msrs);
8894
+free_pml:
8895
+	vmx_destroy_pml_buffer(vmx);
8904 8896
 uninit_vcpu:
8905 8897
 	kvm_vcpu_uninit(&vmx->vcpu);
8906 8898
 free_vcpu:

+ 1 - 0
arch/x86/kvm/x86.c

@@ -3059,6 +3059,7 @@ static void fill_xsave(u8 *dest, struct kvm_vcpu *vcpu)
3059 3059
 	memcpy(dest, xsave, XSAVE_HDR_OFFSET);
3060 3060
 
3061 3061
 	/* Set XSTATE_BV */
3062
+	xstate_bv &= vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE;
3062 3063
 	*(u64 *)(dest + XSAVE_HDR_OFFSET) = xstate_bv;
3063 3064
 
3064 3065
 	/*

+ 13 - 1
arch/x86/platform/goldfish/goldfish.c

@@ -42,10 +42,22 @@ static struct resource goldfish_pdev_bus_resources[] = {
42 42
 	}
43 43
 };
44 44
 
45
+static bool goldfish_enable __initdata;
46
+
47
+static int __init goldfish_setup(char *str)
48
+{
49
+	goldfish_enable = true;
50
+	return 0;
51
+}
52
+__setup("goldfish", goldfish_setup);
53
+
45 54
 static int __init goldfish_init(void)
46 55
 {
56
+	if (!goldfish_enable)
57
+		return -ENODEV;
58
+
47 59
 	platform_device_register_simple("goldfish_pdev_bus", -1,
48
-						goldfish_pdev_bus_resources, 2);
60
+					goldfish_pdev_bus_resources, 2);
49 61
 	return 0;
50 62
 }
51 63
 device_initcall(goldfish_init);

+ 8 - 9
block/blk-mq.c

@@ -1259,12 +1259,9 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
1259 1259
 
1260 1260
 	blk_queue_split(q, &bio, q->bio_split);
1261 1261
 
1262
-	if (!is_flush_fua && !blk_queue_nomerges(q)) {
1263
-		if (blk_attempt_plug_merge(q, bio, &request_count,
1264
-					   &same_queue_rq))
1265
-			return BLK_QC_T_NONE;
1266
-	} else
1267
-		request_count = blk_plug_queued_count(q);
1262
+	if (!is_flush_fua && !blk_queue_nomerges(q) &&
1263
+	    blk_attempt_plug_merge(q, bio, &request_count, &same_queue_rq))
1264
+		return BLK_QC_T_NONE;
1268 1265
 
1269 1266
 	rq = blk_mq_map_request(q, bio, &data);
1270 1267
 	if (unlikely(!rq))
@@ -1355,9 +1352,11 @@ static blk_qc_t blk_sq_make_request(struct request_queue *q, struct bio *bio)
1355 1352
 
1356 1353
 	blk_queue_split(q, &bio, q->bio_split);
1357 1354
 
1358
-	if (!is_flush_fua && !blk_queue_nomerges(q) &&
1359
-	    blk_attempt_plug_merge(q, bio, &request_count, NULL))
1360
-		return BLK_QC_T_NONE;
1355
+	if (!is_flush_fua && !blk_queue_nomerges(q)) {
1356
+		if (blk_attempt_plug_merge(q, bio, &request_count, NULL))
1357
+			return BLK_QC_T_NONE;
1358
+	} else
1359
+		request_count = blk_plug_queued_count(q);
1361 1360
 
1362 1361
 	rq = blk_mq_map_request(q, bio, &data);
1363 1362
 	if (unlikely(!rq))

+ 1 - 0
crypto/algapi.c

@@ -357,6 +357,7 @@ int crypto_register_alg(struct crypto_alg *alg)
357 357
 	struct crypto_larval *larval;
358 358
 	int err;
359 359
 
360
+	alg->cra_flags &= ~CRYPTO_ALG_DEAD;
360 361
 	err = crypto_check_alg(alg);
361 362
 	if (err)
362 363
 		return err;

+ 2 - 2
drivers/ata/libata-core.c

@@ -4139,10 +4139,10 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
4139 4139
 	{ "ST380013AS",		"3.20",		ATA_HORKAGE_MAX_SEC_1024 },
4140 4140
 
4141 4141
 	/*
4142
-	 * Device times out with higher max sects.
4142
+	 * These devices time out with higher max sects.
4143 4143
 	 * https://bugzilla.kernel.org/show_bug.cgi?id=121671
4144 4144
 	 */
4145
-	{ "LITEON CX1-JB256-HP", NULL,		ATA_HORKAGE_MAX_SEC_1024 },
4145
+	{ "LITEON CX1-JB*-HP",	NULL,		ATA_HORKAGE_MAX_SEC_1024 },
4146 4146
 
4147 4147
 	/* Devices we expect to fail diagnostics */
4148 4148
 

+ 3 - 0
drivers/ata/sata_mv.c

@@ -4121,6 +4121,9 @@ static int mv_platform_probe(struct platform_device *pdev)
4121 4121
 	host->iomap = NULL;
4122 4122
 	hpriv->base = devm_ioremap(&pdev->dev, res->start,
4123 4123
 				   resource_size(res));
4124
+	if (!hpriv->base)
4125
+		return -ENOMEM;
4126
+
4124 4127
 	hpriv->base -= SATAHC0_REG_BASE;
4125 4128
 
4126 4129
 	hpriv->clk = clk_get(&pdev->dev, NULL);

+ 5 - 6
drivers/base/memory.c

@@ -388,30 +388,29 @@ static ssize_t show_valid_zones(struct device *dev,
388 388
 {
389 389
 	struct memory_block *mem = to_memory_block(dev);
390 390
 	unsigned long start_pfn, end_pfn;
391
+	unsigned long valid_start, valid_end;
391 392
 	unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
392
-	struct page *first_page;
393 393
 	struct zone *zone;
394 394
 
395 395
 	start_pfn = section_nr_to_pfn(mem->start_section_nr);
396 396
 	end_pfn = start_pfn + nr_pages;
397
-	first_page = pfn_to_page(start_pfn);
398 397
 
399 398
 	/* The block contains more than one zone can not be offlined. */
400
-	if (!test_pages_in_a_zone(start_pfn, end_pfn))
399
+	if (!test_pages_in_a_zone(start_pfn, end_pfn, &valid_start, &valid_end))
401 400
 		return sprintf(buf, "none\n");
402 401
 
403
-	zone = page_zone(first_page);
402
+	zone = page_zone(pfn_to_page(valid_start));
404 403
 
405 404
 	if (zone_idx(zone) == ZONE_MOVABLE - 1) {
406 405
 		/*The mem block is the last memoryblock of this zone.*/
407
-		if (end_pfn == zone_end_pfn(zone))
406
+		if (valid_end == zone_end_pfn(zone))
408 407
 			return sprintf(buf, "%s %s\n",
409 408
 					zone->name, (zone + 1)->name);
410 409
 	}
411 410
 
412 411
 	if (zone_idx(zone) == ZONE_MOVABLE) {
413 412
 		/*The mem block is the first memoryblock of ZONE_MOVABLE.*/
414
-		if (start_pfn == zone->zone_start_pfn)
413
+		if (valid_start == zone->zone_start_pfn)
415 414
 			return sprintf(buf, "%s %s\n",
416 415
 					zone->name, (zone - 1)->name);
417 416
 	}

+ 0 - 18
drivers/block/loop.c

@@ -712,24 +712,6 @@ static inline int is_loop_device(struct file *file)
712 712
 	return i && S_ISBLK(i->i_mode) && MAJOR(i->i_rdev) == LOOP_MAJOR;
713 713
 }
714 714
 
715
-/*
716
- * for AUFS
717
- * no get/put for file.
718
- */
719
-struct file *loop_backing_file(struct super_block *sb)
720
-{
721
-	struct file *ret;
722
-	struct loop_device *l;
723
-
724
-	ret = NULL;
725
-	if (MAJOR(sb->s_dev) == LOOP_MAJOR) {
726
-		l = sb->s_bdev->bd_disk->private_data;
727
-		ret = l->lo_backing_file;
728
-	}
729
-	return ret;
730
-}
731
-EXPORT_SYMBOL_GPL(loop_backing_file);
732
-
733 715
 /* loop sysfs attributes */
734 716
 
735 717
 static ssize_t loop_attr_show(struct device *dev, char *page,

+ 1 - 1
drivers/gpu/drm/drm_dp_mst_topology.c

@@ -1812,7 +1812,7 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
1812 1812
 				mgr->payloads[i].num_slots = req_payload.num_slots;
1813 1813
 			} else if (mgr->payloads[i].num_slots) {
1814 1814
 				mgr->payloads[i].num_slots = 0;
1815
-				drm_dp_destroy_payload_step1(mgr, port, port->vcpi.vcpi, &mgr->payloads[i]);
1815
+				drm_dp_destroy_payload_step1(mgr, port, mgr->payloads[i].vcpi, &mgr->payloads[i]);
1816 1816
 				req_payload.payload_state = mgr->payloads[i].payload_state;
1817 1817
 				mgr->payloads[i].start_slot = 0;
1818 1818
 			}

+ 7 - 0
drivers/gpu/drm/drm_modes.c

@@ -1401,6 +1401,13 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
1401 1401
 		return NULL;
1402 1402
 
1403 1403
 	mode->type |= DRM_MODE_TYPE_USERDEF;
1404
+	/* fix up 1368x768: GFT/CVT can't express 1366 width due to alignment */
1405
+	if (cmd->xres == 1366 && mode->hdisplay == 1368) {
1406
+		mode->hdisplay = 1366;
1407
+		mode->hsync_start--;
1408
+		mode->hsync_end--;
1409
+		drm_mode_set_name(mode);
1410
+	}
1404 1411
 	drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
1405 1412
 	return mode;
1406 1413
 }

+ 5 - 4
drivers/gpu/drm/i915/intel_crt.c

@@ -445,6 +445,7 @@ static bool intel_crt_detect_ddc(struct drm_connector *connector)
445 445
 	struct drm_i915_private *dev_priv = crt->base.base.dev->dev_private;
446 446
 	struct edid *edid;
447 447
 	struct i2c_adapter *i2c;
448
+	bool ret = false;
448 449
 
449 450
 	BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
450 451
 
@@ -461,17 +462,17 @@ static bool intel_crt_detect_ddc(struct drm_connector *connector)
461 462
 		 */
462 463
 		if (!is_digital) {
463 464
 			DRM_DEBUG_KMS("CRT detected via DDC:0x50 [EDID]\n");
464
-			return t