AFS series, with some iov_iter bits included. Backmerge of NFS client
branch is due to conflict between sunrpc changes in there and
iov_iter_{k,b}vec()
calling conventions change in iov_iter part; if you prefer to do that yourself,
just merge work.afs^^ and cherry-pick work.afs HEAD into
uenbacher
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
Acked-by: Andreas Gruenbacher
Reviewed-by: Jan Kara
---
v2: change *acl to *@acl
fs/posix_acl.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- linux-next-20181101.orig/fs/posix_acl.c
+++ linux-next-20181101/fs/posix_acl
AFS series, with some iov_iter bits included. Backmerge of NFS client
branch is due to conflict between sunrpc changes in there and
iov_iter_{k,b}vec()
calling conventions change in iov_iter part; if you prefer to do that yourself,
just merge work.afs^^ and cherry-pick work.afs HEAD into
uenbacher
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
Acked-by: Andreas Gruenbacher
Reviewed-by: Jan Kara
---
v2: change *acl to *@acl
fs/posix_acl.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- linux-next-20181101.orig/fs/posix_acl.c
+++ linux-next-20181101/fs/posix_acl
From: Randy Dunlap
Fix a source file reference location to the correct path name.
Signed-off-by: Randy Dunlap
Cc: Josh Poimboeuf
---
scripts/faddr2line |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20181101.orig/scripts/faddr2line
+++ linux-next-20181101/scripts
From: Randy Dunlap
Fix a source file reference location to the correct path name.
Signed-off-by: Randy Dunlap
Cc: Josh Poimboeuf
---
scripts/faddr2line |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20181101.orig/scripts/faddr2line
+++ linux-next-20181101/scripts
, 1 insertion(+)
--- linux-next-20181101.orig/include/linux/w1.h
+++ linux-next-20181101/include/linux/w1.h
@@ -266,6 +266,7 @@ struct w1_family_ops {
* @family_entry: family linked list
* @fid: 8 bit family identifier
* @fops: operations for this family
, 1 insertion(+)
--- linux-next-20181101.orig/include/linux/w1.h
+++ linux-next-20181101/include/linux/w1.h
@@ -266,6 +266,7 @@ struct w1_family_ops {
* @family_entry: family linked list
* @fid: 8 bit family identifier
* @fops: operations for this family
Reviewed-by: Miquel Raynal
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Jacopo Mondi
Cc: Magnus Damm
Cc: linux-...@lists.infradead.org
Cc: linux...@vger.kernel.org
---
arch/sh/boards/mach-kfr2r09/setup.c |1 -
1 file changed, 1 deletion(-)
--- linux-next-20181101.orig/arch/sh/boards/mach-kfr2r
Reviewed-by: Miquel Raynal
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Jacopo Mondi
Cc: Magnus Damm
Cc: linux-...@lists.infradead.org
Cc: linux...@vger.kernel.org
---
arch/sh/boards/mach-kfr2r09/setup.c |1 -
1 file changed, 1 deletion(-)
--- linux-next-20181101.orig/arch/sh/boards/mach-kfr2r
Quoting Ricardo Ribalda Delgado (2018-11-01 07:40:39)
> All Tull reported that there might be a great ammount of drivers with
> imbalance on clk_add_provider. This is an issue for Device tree overlays
> (and also a bug) https://lkml.org/lkml/2018/10/18/1103
>
> This patchset implement a devm_
Quoting Ricardo Ribalda Delgado (2018-11-01 07:40:39)
> All Tull reported that there might be a great ammount of drivers with
> imbalance on clk_add_provider. This is an issue for Device tree overlays
> (and also a bug) https://lkml.org/lkml/2018/10/18/1103
>
> This patchset implement a devm_
On Fri, Oct 05, 2018 at 09:32:45AM +0200, Christoph Hellwig wrote:
> On Fri, Sep 28, 2018 at 04:17:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > When using initramfs-tools with only the necessary dependencies to mount
> > the root filesystem, it will fail to include nvme drivers for a root
On Fri, Oct 05, 2018 at 09:32:45AM +0200, Christoph Hellwig wrote:
> On Fri, Sep 28, 2018 at 04:17:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > When using initramfs-tools with only the necessary dependencies to mount
> > the root filesystem, it will fail to include nvme drivers for a root
When using initramfs-tools with only the necessary dependencies to mount
the root filesystem, it will fail to include nvme drivers for a root on a
multipath nvme. That happens because the slaves relationship is not
present.
As discussed in [1], using slaves will break lsblk, because the slaves
> (Commit 258ba8e089db23f760139266c232f01bad73f85c from linux-rcu)
>
> This commit reverts a series of commits starting with fcc635436501 ("rcu:
> Make expedited GPs handle CPU 0 being offline") and its successors, thus
> queueing each rcu_node structure's expedited grace-period initialization
>
On Thu, 2018-11-01 at 14:47 -0700, Andrew Morton wrote:
> On Fri, 2 Nov 2018 01:00:07 +0800 wrote:
>
> > From: Miles Chen
> >
> > The page owner read might allocate a large size of memory with
> > a large read count. Allocation fails can easily occur when doing
> > high order allocations.
> >
When using initramfs-tools with only the necessary dependencies to mount
the root filesystem, it will fail to include nvme drivers for a root on a
multipath nvme. That happens because the slaves relationship is not
present.
As discussed in [1], using slaves will break lsblk, because the slaves
> (Commit 258ba8e089db23f760139266c232f01bad73f85c from linux-rcu)
>
> This commit reverts a series of commits starting with fcc635436501 ("rcu:
> Make expedited GPs handle CPU 0 being offline") and its successors, thus
> queueing each rcu_node structure's expedited grace-period initialization
>
On Thu, 2018-11-01 at 14:47 -0700, Andrew Morton wrote:
> On Fri, 2 Nov 2018 01:00:07 +0800 wrote:
>
> > From: Miles Chen
> >
> > The page owner read might allocate a large size of memory with
> > a large read count. Allocation fails can easily occur when doing
> > high order allocations.
> >
> Since it is no longer invoked from the softirq people run into OOM more
> often if the priority of the RCU thread is too low. Making boosting
> default on RT should help in those case and it can be switched off if
> someone knows better.
>
> Signed-off-by: Sebastian Andrzej Siewior
>
> diff
> Since it is no longer invoked from the softirq people run into OOM more
> often if the priority of the RCU thread is too low. Making boosting
> default on RT should help in those case and it can be switched off if
> someone knows better.
>
> Signed-off-by: Sebastian Andrzej Siewior
>
> diff
On Thu, Nov 1, 2018 at 2:24 PM Linus Torvalds
wrote:
>
> On Thu, Nov 1, 2018 at 12:31 PM Rich Felker wrote:
> >
> > See my other emails in this thread. You would register the *address*
> > (in TLS) of a function pointer object pointing to the handler, rather
> > than the function address of the
On Thu, Nov 1, 2018 at 2:24 PM Linus Torvalds
wrote:
>
> On Thu, Nov 1, 2018 at 12:31 PM Rich Felker wrote:
> >
> > See my other emails in this thread. You would register the *address*
> > (in TLS) of a function pointer object pointing to the handler, rather
> > than the function address of the
> With RT_FULL we get the below wreckage:
The code that this applies to has itself been fully frobbed as of the
current merge window. I believe that it should now work in -rt as is,
but who knows? ;-)
Thanx, Paul
> [ 126.060484]
> With RT_FULL we get the below wreckage:
The code that this applies to has itself been fully frobbed as of the
current merge window. I believe that it should now work in -rt as is,
but who knows? ;-)
Thanx, Paul
> [ 126.060484]
> The Linux kernel has long RCU-bh read-side critical sections that
> intolerably increase scheduling latency under mainline's RCU-bh rules,
> which include RCU-bh read-side critical sections being non-preemptible.
> This patch therefore arranges for RCU-bh to be implemented in terms of
>
> The Linux kernel has long RCU-bh read-side critical sections that
> intolerably increase scheduling latency under mainline's RCU-bh rules,
> which include RCU-bh read-side critical sections being non-preemptible.
> This patch therefore arranges for RCU-bh to be implemented in terms of
>
> Implementing RCU-bh in terms of RCU-preempt makes the system vulnerable
> to network-based denial-of-service attacks. This patch therefore
> makes __do_softirq() invoke rcu_bh_qs(), but only when __do_softirq()
> is running in ksoftirqd context. A wrapper layer in interposed so that
> other
> Implementing RCU-bh in terms of RCU-preempt makes the system vulnerable
> to network-based denial-of-service attacks. This patch therefore
> makes __do_softirq() invoke rcu_bh_qs(), but only when __do_softirq()
> is running in ksoftirqd context. A wrapper layer in interposed so that
> other
> The current check via srcu_online is slightly racy because after looking
> at srcu_online there could be an interrupt that interrupted us long
> enough until the CPU we checked against went offline.
I don't see how this can happen, even in -rt. The call to
srcu_offline_cpu() happens very early
> The current check via srcu_online is slightly racy because after looking
> at srcu_online there could be an interrupt that interrupted us long
> enough until the CPU we checked against went offline.
I don't see how this can happen, even in -rt. The call to
srcu_offline_cpu() happens very early
On 01.11.2018 [12:03:40 -0700], Nishanth Aravamudan wrote:
> Hi,
>
> tl;dr: I see a kernel NULL pointer dereference with Linus' master
> (7c6c54b5) when enabling the IO cgroup2 controller at runtime. Is this
> PEBKAC and if so what config option am I missing?
Actually, this might be totally
On 01.11.2018 [12:03:40 -0700], Nishanth Aravamudan wrote:
> Hi,
>
> tl;dr: I see a kernel NULL pointer dereference with Linus' master
> (7c6c54b5) when enabling the IO cgroup2 controller at runtime. Is this
> PEBKAC and if so what config option am I missing?
Actually, this might be totally
This patch allows the endianness of the JFSS2 filesystem to be
specified by config options.
It defaults to native-endian (the previously hard-coded option).
Some architectures benefit from having a single known endianness
of JFFS2 filesystem (for data, not executables) independent of the
This patch allows the endianness of the JFSS2 filesystem to be
specified by config options.
It defaults to native-endian (the previously hard-coded option).
Some architectures benefit from having a single known endianness
of JFFS2 filesystem (for data, not executables) independent of the
This patch series adds the cpu topology for RISC-V. It contains
both the DT binding and actual source code. It has been tested on
QEMU & Unleashed board.
The idea is based on cpu-map in ARM with changes related to how
we define SMT systems. The reason for adopting a similar approach
to ARM as I
This patch series adds the cpu topology for RISC-V. It contains
both the DT binding and actual source code. It has been tested on
QEMU & Unleashed board.
The idea is based on cpu-map in ARM with changes related to how
we define SMT systems. The reason for adopting a similar approach
to ARM as I
Currently, cpu topology is not defined for RISC-V.
Parse cpu-topology from a new DT entry "cpu-topology"
to create different cpu sibling maps.
As of now, only bare minimum requirements are implemented
but it is capable of describing any type of topology in future.
CPU topology after applying the
Currently, cpu topology is not defined for RISC-V.
Parse cpu-topology from a new DT entry "cpu-topology"
to create different cpu sibling maps.
As of now, only bare minimum requirements are implemented
but it is capable of describing any type of topology in future.
CPU topology after applying the
Define a RISC-V cpu topology. This is based on cpu-map in ARM world.
But it doesn't need a separate thread node for defining SMT systems.
Multiple cpu phandle properties can be parsed to identify the sibling
hardware threads. Moreover, we do not have cluster concept in RISC-V.
So package is a
Define a RISC-V cpu topology. This is based on cpu-map in ARM world.
But it doesn't need a separate thread node for defining SMT systems.
Multiple cpu phandle properties can be parsed to identify the sibling
hardware threads. Moreover, we do not have cluster concept in RISC-V.
So package is a
> The forcing of an expedited grace period is an expensive and very
> RT-application unfriendly operation, as it forcibly preempts all running
> tasks on CPUs which are preventing the gp from expiring.
>
> By default, as a policy decision, disable the expediting of grace
> periods (after boot) on
> The forcing of an expedited grace period is an expensive and very
> RT-application unfriendly operation, as it forcibly preempts all running
> tasks on CPUs which are preventing the gp from expiring.
>
> By default, as a policy decision, disable the expediting of grace
> periods (after boot) on
On Thu, Nov 01, 2018 at 11:25:31AM -0400, Yangtao Li wrote:
> Signed-off-by: Yangtao Li
> ---
> arch/arm64/kernel/crash_dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
> index
On Thu, Nov 01, 2018 at 11:25:31AM -0400, Yangtao Li wrote:
> Signed-off-by: Yangtao Li
> ---
> arch/arm64/kernel/crash_dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c
> index
--
Miss Aminata musa ibrahim from Libya, I am 22 years old, I am in St.
Christopher's Parish for refugee in Burkina Faso under United Nations
High commission for Refugee ,I lost my parents in the recent war in
Libya, right now am in Burkina Faso, please save my life i am in danger
need
--
Miss Aminata musa ibrahim from Libya, I am 22 years old, I am in St.
Christopher's Parish for refugee in Burkina Faso under United Nations
High commission for Refugee ,I lost my parents in the recent war in
Libya, right now am in Burkina Faso, please save my life i am in danger
need
On Fri, Oct 26, 2018 at 2:36 AM James Morris wrote:
>
> From David: "Provide five new operations in the key_type struct that can
> be used to provide access to asymmetric key operations. These will be
> implemented for the asymmetric key type in a later patch and may refer to
> a key retained in
On Fri, Oct 26, 2018 at 2:36 AM James Morris wrote:
>
> From David: "Provide five new operations in the key_type struct that can
> be used to provide access to asymmetric key operations. These will be
> implemented for the asymmetric key type in a later patch and may refer to
> a key retained in
On Thu, 2018-10-11 at 17:35 +0200, Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Feng Tang
>
> commit 05ab1d8a4b36ee912b7087c6da127439ed0a903e upstream.
This backport is incorrect. The part that
On Thu, 2018-10-11 at 17:35 +0200, Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Feng Tang
>
> commit 05ab1d8a4b36ee912b7087c6da127439ed0a903e upstream.
This backport is incorrect. The part that
- On Nov 1, 2018, at 11:00 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Nov 1, 2018 at 12:57 PM Mathieu Desnoyers
> wrote:
>>
>> > I think the graceful recovery is to simply return:
>> >
>> > if (WARN_ON(cond))
>> > return;
>> >
>> > is better than
- On Nov 1, 2018, at 11:00 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Thu, Nov 1, 2018 at 12:57 PM Mathieu Desnoyers
> wrote:
>>
>> > I think the graceful recovery is to simply return:
>> >
>> > if (WARN_ON(cond))
>> > return;
>> >
>> > is better than
On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > Can someone at least confirm whether unwinding from a function prologue
> > > via
> > > .eh_frame (but without .debug_frame) should actually be possible?
> >
> > Yes
On Dienstag, 30. Oktober 2018 23:34:35 CET Milian Wolff wrote:
> On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > > Can someone at least confirm whether unwinding from a function prologue
> > > via
> > > .eh_frame (but without .debug_frame) should actually be possible?
> >
> > Yes
On Thu, Nov 1, 2018 at 3:05 PM Al Viro wrote:
>
> Do you mind if we end up with work.mount rebased?
> The usual objections re testing in -next do not apply in this case,
> AFAICS...
I was assuming that the work.mount branch would be entirely re-done, yes.
Linus
On Thu, Nov 1, 2018 at 3:05 PM Al Viro wrote:
>
> Do you mind if we end up with work.mount rebased?
> The usual objections re testing in -next do not apply in this case,
> AFAICS...
I was assuming that the work.mount branch would be entirely re-done, yes.
Linus
On Thu, Nov 1, 2018 at 12:57 PM Mathieu Desnoyers
wrote:
>
> > I think the graceful recovery is to simply return:
> >
> > if (WARN_ON(cond))
> > return;
> >
> > is better than just
> >
> > BUG_ON(cond);
> >
> > As that's what Linus made pretty clear at the Maintainer's
On Thu, Nov 1, 2018 at 12:57 PM Mathieu Desnoyers
wrote:
>
> > I think the graceful recovery is to simply return:
> >
> > if (WARN_ON(cond))
> > return;
> >
> > is better than just
> >
> > BUG_ON(cond);
> >
> > As that's what Linus made pretty clear at the Maintainer's
On Wed 2018-10-24 00:57:50, David Howells wrote:
> Remove the undefinition of READ and WRITE because these constants may be
> used elsewhere in subsequently included header files, thus breaking them.
>
> These constants don't actually appear to be used in the driver, so the
> undefinition seems
On Wed 2018-10-24 00:57:50, David Howells wrote:
> Remove the undefinition of READ and WRITE because these constants may be
> used elsewhere in subsequently included header files, thus breaking them.
>
> These constants don't actually appear to be used in the driver, so the
> undefinition seems
On Thu, Nov 01, 2018 at 11:33:31AM -0700, Linus Torvalds wrote:
> Al - can I ask you to look at helping David with something like that?
> You tend to be very good at generating those patch-series with
> "obviously no changes" for the individual patches, but the end result
> ends up being totally
On Thu, Nov 01, 2018 at 11:33:31AM -0700, Linus Torvalds wrote:
> Al - can I ask you to look at helping David with something like that?
> You tend to be very good at generating those patch-series with
> "obviously no changes" for the individual patches, but the end result
> ends up being totally
Hi!
> This makes keyboard/touchpad work on a DT MMP2 platform.
For the series:
Acked-by: Pavel Machek
Tested-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description:
Hi!
> This makes keyboard/touchpad work on a DT MMP2 platform.
For the series:
Acked-by: Pavel Machek
Tested-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description:
On Thu, Nov 1, 2018 at 2:06 PM Miklos Szeredi wrote:
>
> This contains a mix of fixes and cleanups.
Pulled,
Linus
On Thu, Nov 1, 2018 at 2:06 PM Miklos Szeredi wrote:
>
> This contains a mix of fixes and cleanups.
Pulled,
Linus
Linus,
On Wed, Oct 31, 2018 at 10:22 PM Richard Weinberger wrote:
> The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:
>
> Linux 4.19 (2018-10-22 07:37:37 +0100)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-ubifs.git
Linus,
On Wed, Oct 31, 2018 at 10:22 PM Richard Weinberger wrote:
> The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:
>
> Linux 4.19 (2018-10-22 07:37:37 +0100)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-ubifs.git
On Thu, Nov 1, 2018 at 6:17 PM Sven Van Asbroeck wrote:
> >> +static DEVICE_ATTR_RO(version);
> >
> > Do you need this in userspace really?
> >
> >> +static DEVICE_ATTR_RO(design_number);
> >
> > And this?
>
> Unfortunately, I do :(
> The application software reads these out and displays them in
On Thu, Nov 1, 2018 at 6:17 PM Sven Van Asbroeck wrote:
> >> +static DEVICE_ATTR_RO(version);
> >
> > Do you need this in userspace really?
> >
> >> +static DEVICE_ATTR_RO(design_number);
> >
> > And this?
>
> Unfortunately, I do :(
> The application software reads these out and displays them in
On Thu, Nov 01 2018, Paul E. McKenney wrote:
> On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
>> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
>> > On Wed, Oct 24 2018, Josh Triplett wrote:
>> >
>> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> >
On Thu, Nov 01 2018, Paul E. McKenney wrote:
> On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
>> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
>> > On Wed, Oct 24 2018, Josh Triplett wrote:
>> >
>> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> >
Since shiftfs inodes map to dentries in the lower fs, two links
to the same lowerfs inode create separate inodes in shiftfs. This
causes problems for inotify, as a watch on one of these files in
shiftfs will not see changes made to the underlying inode via the
other file.
Fix this by updating
Since shiftfs inodes map to dentries in the lower fs, two links
to the same lowerfs inode create separate inodes in shiftfs. This
causes problems for inotify, as a watch on one of these files in
shiftfs will not see changes made to the underlying inode via the
other file.
Fix this by updating
Not all inode permission checks go through the permission
callback, e.g. some checks related to file capabilities. Always
copy up the inode attrs to ensure these checks work as expected.
Also introduce helpers helpers for shifting kernel ids from one
user ns to another, as this is an operation
Do not assume that ids from the lower filesystem are from
init_user_ns. Instead, translate them from that filesystem's
s_user_ns and then to the shiftfs user ns.
Signed-off-by: Seth Forshee
---
fs/shiftfs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/shiftfs.c
Not all inode permission checks go through the permission
callback, e.g. some checks related to file capabilities. Always
copy up the inode attrs to ensure these checks work as expected.
Also introduce helpers helpers for shifting kernel ids from one
user ns to another, as this is an operation
Do not assume that ids from the lower filesystem are from
init_user_ns. Instead, translate them from that filesystem's
s_user_ns and then to the shiftfs user ns.
Signed-off-by: Seth Forshee
---
fs/shiftfs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/shiftfs.c
Signed-off-by: Seth Forshee
---
fs/Kconfig | 10 +++
fs/shiftfs.c | 185 +++
2 files changed, 195 insertions(+)
diff --git a/fs/Kconfig b/fs/Kconfig
index 392c5a41a9f9..691f3c4fc7eb 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -121,6 +121,16 @@
shiftfs mounts cannot be nested for two reasons -- global
CAP_SYS_ADMIN is required to set up a mark mount, and a single
functional shiftfs mount meets the filesystem stacking depth
limit.
The CAP_SYS_ADMIN requirement can be relaxed. All of the kernel
ids in a mount must be within that mount's
Signed-off-by: Seth Forshee
---
fs/Kconfig | 10 +++
fs/shiftfs.c | 185 +++
2 files changed, 195 insertions(+)
diff --git a/fs/Kconfig b/fs/Kconfig
index 392c5a41a9f9..691f3c4fc7eb 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -121,6 +121,16 @@
shiftfs mounts cannot be nested for two reasons -- global
CAP_SYS_ADMIN is required to set up a mark mount, and a single
functional shiftfs mount meets the filesystem stacking depth
limit.
The CAP_SYS_ADMIN requirement can be relaxed. All of the kernel
ids in a mount must be within that mount's
From: James Bottomley
This allows any subtree to be uid/gid shifted and bound elsewhere. It
does this by operating simlarly to overlayfs. Its primary use is for
shifting the underlying uids of filesystems used to support
unpriviliged (uid shifted) containers. The usual use case here is
that
I've done some work to fix and enhance shiftfs for a number of use
cases, so that we would have an idea what a more full-featured shiftfs
would look like. I'm intending for these to serve as a point of
reference for discussing id shifting mounts/filesystems at plumbers in a
couple of weeks [1].
From: James Bottomley
This allows any subtree to be uid/gid shifted and bound elsewhere. It
does this by operating simlarly to overlayfs. Its primary use is for
shifting the underlying uids of filesystems used to support
unpriviliged (uid shifted) containers. The usual use case here is
that
I've done some work to fix and enhance shiftfs for a number of use
cases, so that we would have an idea what a more full-featured shiftfs
would look like. I'm intending for these to serve as a point of
reference for discussing id shifting mounts/filesystems at plumbers in a
couple of weeks [1].
On Fri, 2 Nov 2018 01:00:07 +0800 wrote:
> From: Miles Chen
>
> The page owner read might allocate a large size of memory with
> a large read count. Allocation fails can easily occur when doing
> high order allocations.
>
> Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation
>
On Fri, 2 Nov 2018 01:00:07 +0800 wrote:
> From: Miles Chen
>
> The page owner read might allocate a large size of memory with
> a large read count. Allocation fails can easily occur when doing
> high order allocations.
>
> Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation
>
On Thu, Nov 1, 2018 at 2:23 PM Rob Herring wrote:
>
> Please pull a couple of fixes for rc1.
Pulled,
Linus
On Thu, Nov 1, 2018 at 2:23 PM Rob Herring wrote:
>
> Please pull a couple of fixes for rc1.
Pulled,
Linus
Hi!
> > > > I've no wish to be disputatious, but it does seem that the definition of
> > > > "stable" has changed, and not necessarily for the better, if it's now a
> > > > home for small gains: I thought we left those to upstream.
> >
> > > This is in the SLES kernel for a reason, and again,
Hi!
> > > > I've no wish to be disputatious, but it does seem that the definition of
> > > > "stable" has changed, and not necessarily for the better, if it's now a
> > > > home for small gains: I thought we left those to upstream.
> >
> > > This is in the SLES kernel for a reason, and again,
From: Enrico Granata
This driver allows interfacing with the Semtech sx9320, sx9321 and sx9324
proximity sensors via the IIO subsystem.
Signed-off-by: Enrico Granata
---
.../bindings/iio/proximity/sx932x.txt | 54 +
drivers/iio/proximity/Kconfig | 36 +-
From: Enrico Granata
This driver allows interfacing with the Semtech sx9320, sx9321 and sx9324
proximity sensors via the IIO subsystem.
Signed-off-by: Enrico Granata
---
.../bindings/iio/proximity/sx932x.txt | 54 +
drivers/iio/proximity/Kconfig | 36 +-
On Wed, Oct 31, 2018 at 9:18 PM kbuild test robot wrote:
>
> Hi Rob,
>
> FYI, the error/warning still remains.
I replied on another one of these reports that these failures need to
be fixed by using "CONFIG_OF_ALL_DTBS=y CONFIG_DTC=y" instead of just
"CONFIG_OF_ALL_DTBS=y" as specifying kconfig
On Wed, Oct 31, 2018 at 9:18 PM kbuild test robot wrote:
>
> Hi Rob,
>
> FYI, the error/warning still remains.
I replied on another one of these reports that these failures need to
be fixed by using "CONFIG_OF_ALL_DTBS=y CONFIG_DTC=y" instead of just
"CONFIG_OF_ALL_DTBS=y" as specifying kconfig
On Thu, 2018-11-01 at 17:30 -0400, thesve...@gmail.com wrote:
> I am seeing this in my kernel log:
>
> [ 10.235625] tg3 :03:00.0 eth20: No interrupt was generated
> using MSI.
> Switching to INTx mode. Please report this failure to the PCI
> maintainer and include system chipset
On Thu, 2018-11-01 at 17:30 -0400, thesve...@gmail.com wrote:
> I am seeing this in my kernel log:
>
> [ 10.235625] tg3 :03:00.0 eth20: No interrupt was generated
> using MSI.
> Switching to INTx mode. Please report this failure to the PCI
> maintainer and include system chipset
101 - 200 of 1024 matches
Mail list logo
