Hi Paolo,
On Fri, 2018-11-30 at 11:07 +0100, Paolo Bonzini wrote:
> On 30/11/18 08:52, Zhang Yi wrote:
> > Here is a patch-series which adding EPT-Based Sub-page Write Protection
> > Support.
> >
> > Introduction:
> >
> > EPT-Based Sub-page Write Protection referred to as SPP, it is a
Hi Paolo,
On Fri, 2018-11-30 at 11:07 +0100, Paolo Bonzini wrote:
> On 30/11/18 08:52, Zhang Yi wrote:
> > Here is a patch-series which adding EPT-Based Sub-page Write Protection
> > Support.
> >
> > Introduction:
> >
> > EPT-Based Sub-page Write Protection referred to as SPP, it is a
Found warning:
WARNING: EXPORT symbol "gsi_write_channel_scratch" [vmlinux] version generation
failed, symbol will not be versioned.
WARNING: vmlinux.o(.text+0x1e0a0): Section mismatch in reference from the
function valid_phys_addr_range() to the function
.init.text:memblock_is_reserved()
The
Found warning:
WARNING: EXPORT symbol "gsi_write_channel_scratch" [vmlinux] version generation
failed, symbol will not be versioned.
WARNING: vmlinux.o(.text+0x1e0a0): Section mismatch in reference from the
function valid_phys_addr_range() to the function
.init.text:memblock_is_reserved()
The
Found warring:
WARNING: EXPORT symbol "gsi_write_channel_scratch" [vmlinux] version generation
failed, symbol will not be versioned.
WARNING: vmlinux.o(.text+0x1e0a0): Section mismatch in reference from the
function valid_phys_addr_range() to the function
.init.text:memblock_is_reserved()
The
Found warring:
WARNING: EXPORT symbol "gsi_write_channel_scratch" [vmlinux] version generation
failed, symbol will not be versioned.
WARNING: vmlinux.o(.text+0x1e0a0): Section mismatch in reference from the
function valid_phys_addr_range() to the function
.init.text:memblock_is_reserved()
The
# Remove nobuhiro.iwamatsu...@hitachi.com from To.
Hi,
I am already leaving Hitachi.
However, I would like to merge these patches into the kernel. I will
resume work.
Best regards,
Nobuhiro
2018年11月30日(金) 8:33 Kees Cook :
>
> On Sun, Feb 26, 2017 at 5:54 PM Nobuhiro Iwamatsu
> wrote:
> >
# Remove nobuhiro.iwamatsu...@hitachi.com from To.
Hi,
I am already leaving Hitachi.
However, I would like to merge these patches into the kernel. I will
resume work.
Best regards,
Nobuhiro
2018年11月30日(金) 8:33 Kees Cook :
>
> On Sun, Feb 26, 2017 at 5:54 PM Nobuhiro Iwamatsu
> wrote:
> >
The idea here is just to give a demonstration of how one could safely use
the SECCOMP_RET_USER_NOTIF feature to do mount policies. This particular
policy is (as noted in the comment) not very interesting, but it serves to
illustrate how one might apply a policy dodging the various TOCTOU issues.
This patch introduces a means for syscalls matched in seccomp to notify
some other task that a particular filter has been triggered.
The motivation for this is primarily for use with containers. For example,
if a container does an init_module(), we obviously don't want to load this
untrusted
The idea here is just to give a demonstration of how one could safely use
the SECCOMP_RET_USER_NOTIF feature to do mount policies. This particular
policy is (as noted in the comment) not very interesting, but it serves to
illustrate how one might apply a policy dodging the various TOCTOU issues.
This patch introduces a means for syscalls matched in seccomp to notify
some other task that a particular filter has been triggered.
The motivation for this is primarily for use with containers. For example,
if a container does an init_module(), we obviously don't want to load this
untrusted
In the next patch, we're going to use the sd pointer passed to
__seccomp_filter() as the data to pass to userspace. Except that in some
cases (__seccomp_filter(SECCOMP_RET_TRACE), emulate_vsyscall(), every time
seccomp is inovked on power, etc.) the sd pointer will be NULL in order to
force
The const qualifier causes problems for any code that wants to write to the
third argument of the seccomp syscall, as we will do in a future patch in
this series.
The third argument to the seccomp syscall is documented as void *, so
rather than just dropping the const, let's switch everything to
Hi all,
Here's a v9 of the seccomp trap to userspace series. Major changes are:
* drop the whole SIGNALED flag thing. This was confusing to a number of
people, and Oleg pointed out that it makes it fairly easy to get a
task into an uninterruptible sleep. Now, replies to a task with a
In the next patch, we're going to use the sd pointer passed to
__seccomp_filter() as the data to pass to userspace. Except that in some
cases (__seccomp_filter(SECCOMP_RET_TRACE), emulate_vsyscall(), every time
seccomp is inovked on power, etc.) the sd pointer will be NULL in order to
force
The const qualifier causes problems for any code that wants to write to the
third argument of the seccomp syscall, as we will do in a future patch in
this series.
The third argument to the seccomp syscall is documented as void *, so
rather than just dropping the const, let's switch everything to
Hi all,
Here's a v9 of the seccomp trap to userspace series. Major changes are:
* drop the whole SIGNALED flag thing. This was confusing to a number of
people, and Oleg pointed out that it makes it fairly easy to get a
task into an uninterruptible sleep. Now, replies to a task with a
According to documentation in include/asm-generic/syscall.h,
if error argument of syscall_set_return_value() is nonzero,
it is a negated errno.
This change fixes syscall_set_return_value() implementation on sh
to match its own syscall_get_error(), the documentation, and other
architectures where
According to documentation in include/asm-generic/syscall.h,
if error argument of syscall_set_return_value() is nonzero,
it is a negated errno.
This change fixes syscall_set_return_value() implementation on sh
to match its own syscall_get_error(), the documentation, and other
architectures where
According to documentation in include/asm-generic/syscall.h,
syscall_get_error() should return -ERRORCODE if the system call failed.
This change fixes syscall_get_error() implementation on ia64 to match
its own syscall_set_return_value(), the documentation, and other
architectures where
According to documentation in include/asm-generic/syscall.h,
syscall_get_error() should return -ERRORCODE if the system call failed.
This change fixes syscall_get_error() implementation on nios2 to match
its own syscall_set_return_value(), the documentation, and other
architectures where
According to documentation in include/asm-generic/syscall.h,
syscall_get_error() should return -ERRORCODE if the system call failed.
This change fixes syscall_get_error() implementation on ia64 to match
its own syscall_set_return_value(), the documentation, and other
architectures where
According to documentation in include/asm-generic/syscall.h,
syscall_get_error() should return -ERRORCODE if the system call failed.
This change fixes syscall_get_error() implementation on nios2 to match
its own syscall_set_return_value(), the documentation, and other
architectures where
According to documentation in include/asm-generic/syscall.h,
if error argument of syscall_set_return_value() is nonzero,
it is a negated errno.
This change fixes syscall_set_return_value() implementation on
microblaze to match its own syscall_get_error(), the documentation,
and other
According to documentation in include/asm-generic/syscall.h,
if error argument of syscall_set_return_value() is nonzero,
it is a negated errno.
This change fixes syscall_set_return_value() implementation on
microblaze to match its own syscall_get_error(), the documentation,
and other
Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG
and AO_GPIO_O.
These bits of controlling output level are remapped to the new register
AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable.
These bits of controlling pull enable are remapped to the new
Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG
and AO_GPIO_O.
These bits of controlling output level are remapped to the new register
AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable.
These bits of controlling pull enable are remapped to the new
On 2018/12/3 10:46, Yueyi Li wrote:
>
>
> On 2018/11/30 20:20, Dave Rodgman wrote:
>>> On 2018/11/30 0:49, Dave Rodgman wrote:
On 28/11/2018 1:52 pm, David Sterba wrote:
> The fix is adding a few branches to code that's supposed to be as
> fast
> as possible. The branches
On 2018/12/3 10:46, Yueyi Li wrote:
>
>
> On 2018/11/30 20:20, Dave Rodgman wrote:
>>> On 2018/11/30 0:49, Dave Rodgman wrote:
On 28/11/2018 1:52 pm, David Sterba wrote:
> The fix is adding a few branches to code that's supposed to be as
> fast
> as possible. The branches
Hi Kirill,
On 11/23/18 at 06:58pm, Kirill A. Shutemov wrote:
> > Thanks for this fix. One small concern is whether we can put LDT
> > remap in other place, e.g shrink KASAN area and save one pgd size for
> > it, Just from Redhat's enterprise relase point of view, we don't
> > enable CONFIG_KASAN,
Hi Kirill,
On 11/23/18 at 06:58pm, Kirill A. Shutemov wrote:
> > Thanks for this fix. One small concern is whether we can put LDT
> > remap in other place, e.g shrink KASAN area and save one pgd size for
> > it, Just from Redhat's enterprise relase point of view, we don't
> > enable CONFIG_KASAN,
On 2018/11/30 20:20, Dave Rodgman wrote:
>> On 2018/11/30 0:49, Dave Rodgman wrote:
>>> On 28/11/2018 1:52 pm, David Sterba wrote:
>>>
The fix is adding a few branches to code that's supposed to be as fast
as possible. The branches would be evaluated all the time while
protecting
On 2018/11/30 20:20, Dave Rodgman wrote:
>> On 2018/11/30 0:49, Dave Rodgman wrote:
>>> On 28/11/2018 1:52 pm, David Sterba wrote:
>>>
The fix is adding a few branches to code that's supposed to be as fast
as possible. The branches would be evaluated all the time while
protecting
On (12/03/18 11:41), Minchan Kim wrote:
> On Mon, Dec 03, 2018 at 11:30:40AM +0900, Sergey Senozhatsky wrote:
> > On (12/03/18 08:18), Minchan Kim wrote:
> > >
> > > Per andrew's comment:
> > > https://lkml.org/lkml/2018/11/27/156
> > >
> > > I need to fix it to represent 4K always.
> >
> >
On (12/03/18 11:41), Minchan Kim wrote:
> On Mon, Dec 03, 2018 at 11:30:40AM +0900, Sergey Senozhatsky wrote:
> > On (12/03/18 08:18), Minchan Kim wrote:
> > >
> > > Per andrew's comment:
> > > https://lkml.org/lkml/2018/11/27/156
> > >
> > > I need to fix it to represent 4K always.
> >
> >
The sw2iso count should cover ARM LDO ramp-up time,
the MAX ARM LDO ramp-up time may be up to more than
100us on some boards, this patch sets sw2iso to 0xf
(~384us) which is the reset value, and it is much
more safe to cover different boards, since we have
observed that some customer boards failed
The sw2iso count should cover ARM LDO ramp-up time,
the MAX ARM LDO ramp-up time may be up to more than
100us on some boards, this patch sets sw2iso to 0xf
(~384us) which is the reset value, and it is much
more safe to cover different boards, since we have
observed that some customer boards failed
On Mon, Dec 03, 2018 at 11:30:40AM +0900, Sergey Senozhatsky wrote:
> On (12/03/18 08:18), Minchan Kim wrote:
> >
> > Per andrew's comment:
> > https://lkml.org/lkml/2018/11/27/156
> >
> > I need to fix it to represent 4K always.
>
> Aha.
>
> Then we need to increase bd_writes PAGE_SIZE/4K
On Mon, Dec 03, 2018 at 11:30:40AM +0900, Sergey Senozhatsky wrote:
> On (12/03/18 08:18), Minchan Kim wrote:
> >
> > Per andrew's comment:
> > https://lkml.org/lkml/2018/11/27/156
> >
> > I need to fix it to represent 4K always.
>
> Aha.
>
> Then we need to increase bd_writes PAGE_SIZE/4K
If there are lots of write IO with flash device, it could have a
wearout problem of storage. To overcome the problem, admin needs
to design write limitation to guarantee flash health
for entire product life.
This patch creates a new knob "writeback_limit" on zram.
writeback_limit's default value
If there are lots of write IO with flash device, it could have a
wearout problem of storage. To overcome the problem, admin needs
to design write limitation to guarantee flash health
for entire product life.
This patch creates a new knob "writeback_limit" on zram.
writeback_limit's default value
If blkdev_get fails, we shouldn't do blkdev_put. Otherwise,
kernel emits below log. This patch fixes it.
[ 31.073006] WARNING: CPU: 0 PID: 1893 at fs/block_dev.c:1828
blkdev_put+0x105/0x120
[ 31.075104] Modules linked in:
[ 31.075898] CPU: 0 PID: 1893 Comm: swapoff Not tainted 4.19.0+ #453
To support idle page writeback with upcoming patches, this patch
introduces a new ZRAM_IDLE flag.
Userspace can mark zram slots as "idle" via
"echo all > /sys/block/zramX/idle"
which marks every allocated zram slot as ZRAM_IDLE.
User could see it by
This patch supports new feature "zram idle/huge page writeback".
On zram-swap usecase, zram has usually many idle/huge swap pages.
It's pointless to keep in memory(ie, zram).
To solve the problem, this feature introduces idle/huge page
writeback to backing device so the goal is to save more
bd_stat represents things happened in backing device. Currently,
it supports bd_counts, bd_reads and bd_writes which are helpful
to understand wearout of flash and memory saving.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 ++
[ 254.519728]
[ 254.520311] WARNING: inconsistent lock state
[ 254.520898] 4.19.0+ #390 Not tainted
[ 254.521387]
[ 254.521732] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 254.521732] zram_verify/2095
If blkdev_get fails, we shouldn't do blkdev_put. Otherwise,
kernel emits below log. This patch fixes it.
[ 31.073006] WARNING: CPU: 0 PID: 1893 at fs/block_dev.c:1828
blkdev_put+0x105/0x120
[ 31.075104] Modules linked in:
[ 31.075898] CPU: 0 PID: 1893 Comm: swapoff Not tainted 4.19.0+ #453
To support idle page writeback with upcoming patches, this patch
introduces a new ZRAM_IDLE flag.
Userspace can mark zram slots as "idle" via
"echo all > /sys/block/zramX/idle"
which marks every allocated zram slot as ZRAM_IDLE.
User could see it by
This patch supports new feature "zram idle/huge page writeback".
On zram-swap usecase, zram has usually many idle/huge swap pages.
It's pointless to keep in memory(ie, zram).
To solve the problem, this feature introduces idle/huge page
writeback to backing device so the goal is to save more
bd_stat represents things happened in backing device. Currently,
it supports bd_counts, bd_reads and bd_writes which are helpful
to understand wearout of flash and memory saving.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8 ++
[ 254.519728]
[ 254.520311] WARNING: inconsistent lock state
[ 254.520898] 4.19.0+ #390 Not tainted
[ 254.521387]
[ 254.521732] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 254.521732] zram_verify/2095
This patch does renaming some variables and restructuring
some codes for better redability in writeback and zs_free_page.
Reviewed-by: Joey Pabalinas
Reviewed-by: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 105 +-
Inherently, swap device has many idle pages which are rare touched since
it was allocated. It is never problem if we use storage device as swap.
However, it's just waste for zram-swap.
This patchset supports zram idle page writeback feature.
* Admin can define what is idle page "no access since
Inherently, swap device has many idle pages which are rare touched since
it was allocated. It is never problem if we use storage device as swap.
However, it's just waste for zram-swap.
This patchset supports zram idle page writeback feature.
* Admin can define what is idle page "no access since
This patch does renaming some variables and restructuring
some codes for better redability in writeback and zs_free_page.
Reviewed-by: Joey Pabalinas
Reviewed-by: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 105 +-
On (12/03/18 08:18), Minchan Kim wrote:
>
> Per andrew's comment:
> https://lkml.org/lkml/2018/11/27/156
>
> I need to fix it to represent 4K always.
Aha.
Then we need to increase bd_writes PAGE_SIZE/4K times in writeback_store()?
wb_count = atomic64_inc_return(>stats.bd_writes);
...
On (12/03/18 08:18), Minchan Kim wrote:
>
> Per andrew's comment:
> https://lkml.org/lkml/2018/11/27/156
>
> I need to fix it to represent 4K always.
Aha.
Then we need to increase bd_writes PAGE_SIZE/4K times in writeback_store()?
wb_count = atomic64_inc_return(>stats.bd_writes);
...
This patch fixes the following checkpatch.pl errors:
ERROR: spaces required around that ':' (ctx:VxW)
+torture_type, tag, cxt.debug_lock ? " [debug]": "",
^
Signed-off-by: Wen Yang
CC: Davidlohr Bueso
CC: "Paul E.
This patch fixes the following checkpatch.pl errors:
ERROR: spaces required around that ':' (ctx:VxW)
+torture_type, tag, cxt.debug_lock ? " [debug]": "",
^
Signed-off-by: Wen Yang
CC: Davidlohr Bueso
CC: "Paul E.
Fix the following warnings reported by coccinelle:
kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1
Fix the following warnings reported by coccinelle:
kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:918:2-20: WARNING: Assignment of bool to 0/1
kernel/locking/locktorture.c:949:3-20: WARNING: Assignment of bool to 0/1
On Thu, Nov 22, 2018 at 01:38:56PM +0200, Roger Quadros wrote:
> Hi,
>
> The Programmable Real-Time Unit and Industrial Communication Subsystem
> (PRU-ICSS) is present on various TI SoCs such as AM335x, AM437x, AM57x,
> Keystone 66AK2G, etc. A PRUSS consists of dual 32-bit RISC cores
On Thu, Nov 22, 2018 at 01:38:56PM +0200, Roger Quadros wrote:
> Hi,
>
> The Programmable Real-Time Unit and Industrial Communication Subsystem
> (PRU-ICSS) is present on various TI SoCs such as AM335x, AM437x, AM57x,
> Keystone 66AK2G, etc. A PRUSS consists of dual 32-bit RISC cores
From: Will Deacon Sent: Tuesday, November 27, 2018 2:19
AM
> > > The general approach is for patches 1 and 2 of the series to provide
> > > all the new code under arch/arm64 to enable Hyper-V. But the code
> > > won't get called (or even built) with just these two patches because
> > >
From: Will Deacon Sent: Tuesday, November 27, 2018 2:19
AM
> > > The general approach is for patches 1 and 2 of the series to provide
> > > all the new code under arch/arm64 to enable Hyper-V. But the code
> > > won't get called (or even built) with just these two patches because
> > >
From: Vitaly Kuznetsov Sent: Friday, November 30, 2018
4:54 AM
>
> @@ -466,7 +466,7 @@ union hv_message_flags {
> struct {
> __u8 msg_pending:1;
> __u8 reserved:7;
> - };
> + } __packed;
> };
>
> /* Define port identifier type. */
I think __packed
From: Vitaly Kuznetsov Sent: Friday, November 30, 2018
4:54 AM
>
> @@ -466,7 +466,7 @@ union hv_message_flags {
> struct {
> __u8 msg_pending:1;
> __u8 reserved:7;
> - };
> + } __packed;
> };
>
> /* Define port identifier type. */
I think __packed
With PM enabled, I noticed that pressing a key on the droid4 keyboard will
block deeper idle states for the SoC. Looks like we can fix this by
managing the idle register to gether with the interrupt similar to what
we already do for the GPIO controller.
Note that we now must also disable
I noticed that the Android v3.0.8 kernel on droid4 is using different
keypad values from the mainline kernel and does not have issues with
keys occasionally being stuck until pressed again. Turns out there was
an earlier patch posted to fix this as "Input: omap-keypad: errata i689:
Correct
With PM enabled, I noticed that pressing a key on the droid4 keyboard will
block deeper idle states for the SoC. Looks like we can fix this by
managing the idle register to gether with the interrupt similar to what
we already do for the GPIO controller.
Note that we now must also disable
I noticed that the Android v3.0.8 kernel on droid4 is using different
keypad values from the mainline kernel and does not have issues with
keys occasionally being stuck until pressed again. Turns out there was
an earlier patch posted to fix this as "Input: omap-keypad: errata i689:
Correct
Hi Linus,
On 15/11/2018 11:04, Linus Walleij wrote:
> On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam
> wrote:
>
>> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
>>
>> Signed-off-by: Manivannan Sadhasivam
>
> Patch applied.
>
Could you provide a stable tree for me, so
Hi Linus,
On 15/11/2018 11:04, Linus Walleij wrote:
> On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam
> wrote:
>
>> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
>>
>> Signed-off-by: Manivannan Sadhasivam
>
> Patch applied.
>
Could you provide a stable tree for me, so
On Fri, Nov 30, 2018 at 12:25:21PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 30, 2018 at 10:21:40PM +0800, leo@linaro.org escreveu:
> > On Fri, Nov 30, 2018 at 11:21:54AM +0100, Jiri Olsa wrote:
> > > On Fri, Nov 30, 2018 at 06:06:05PM +0800, Leo Yan wrote:
> > > > Since commit
On Fri, Nov 30, 2018 at 12:25:21PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 30, 2018 at 10:21:40PM +0800, leo@linaro.org escreveu:
> > On Fri, Nov 30, 2018 at 11:21:54AM +0100, Jiri Olsa wrote:
> > > On Fri, Nov 30, 2018 at 06:06:05PM +0800, Leo Yan wrote:
> > > > Since commit
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and
> From: gre...@linuxfoundation.org
> Sent: Sunday, December 2, 2018 7:33 AM
> To: Dexuan Cui
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> ; o...@aepfle.de; jasow...@redhat.com; Michael
>
> From: gre...@linuxfoundation.org
> Sent: Sunday, December 2, 2018 7:33 AM
> To: Dexuan Cui
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; a...@canonical.com; vkuznets
> ; o...@aepfle.de; jasow...@redhat.com; Michael
>
On Sat, Dec 01, 2018 at 02:06:11AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> mm/hmm.c: In function 'hmm_devmem_ref_kill':
> mm/hmm.c:995:21: warning:
> variable 'devmem' set but not used [-Wunused-but-set-variable]
>
> It not used any more since commit
On Sat, Dec 01, 2018 at 02:06:11AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> mm/hmm.c: In function 'hmm_devmem_ref_kill':
> mm/hmm.c:995:21: warning:
> variable 'devmem' set but not used [-Wunused-but-set-variable]
>
> It not used any more since commit
On Sun, Dec 02, 2018 at 08:35:09PM +0100, Miquel Raynal wrote:
> Hi Russell,
>
> Russell King - ARM Linux wrote on Fri, 30 Nov
> 2018 19:00:31 +:
>
> > On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> > > So far the PHY ->xlate() callback was checking if the port was
> > >
On Sun, Dec 02, 2018 at 08:35:09PM +0100, Miquel Raynal wrote:
> Hi Russell,
>
> Russell King - ARM Linux wrote on Fri, 30 Nov
> 2018 19:00:31 +:
>
> > On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> > > So far the PHY ->xlate() callback was checking if the port was
> > >
Just use ->cr_cred->fsuid directly.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h|2 --
net/sunrpc/auth.c |1 -
net/sunrpc/auth_gss/auth_gss.c | 12 ++--
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/include/linux/sunrpc/auth.h
1/ discard 'struct unx_cred'. We don't need any data that
is not already in 'struct rpc_cred'.
2/ Don't keep these creds in a hash table. When a credential
is needed, simply allocate it. When not needed, discard it.
This can easily be faster than performing a lookup on
a shared hash
Just use ->cr_cred->fsuid directly.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h|2 --
net/sunrpc/auth.c |1 -
net/sunrpc/auth_gss/auth_gss.c | 12 ++--
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/include/linux/sunrpc/auth.h
1/ discard 'struct unx_cred'. We don't need any data that
is not already in 'struct rpc_cred'.
2/ Don't keep these creds in a hash table. When a credential
is needed, simply allocate it. When not needed, discard it.
This can easily be faster than performing a lookup on
a shared hash
This now always just does get_rpccred(), so we
don't need an operation pointer to know to do that.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h|2 --
net/sunrpc/auth.c | 12 +---
net/sunrpc/auth_gss/auth_gss.c |2 --
net/sunrpc/auth_null.c
SUNRPC has two sorts of credentials, both of which appear as
"struct rpc_cred".
There are "generic credentials" which are supplied by clients
such as NFS and passed in 'struct rpc_message' to indicate
which user should be used to authorize the request, and there
are low-level credentials such as
This now always just does get_rpccred(), so we
don't need an operation pointer to know to do that.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h|2 --
net/sunrpc/auth.c | 12 +---
net/sunrpc/auth_gss/auth_gss.c |2 --
net/sunrpc/auth_null.c
SUNRPC has two sorts of credentials, both of which appear as
"struct rpc_cred".
There are "generic credentials" which are supplied by clients
such as NFS and passed in 'struct rpc_message' to indicate
which user should be used to authorize the request, and there
are low-level credentials such as
The credential passed in rpc_message.rpc_cred is always a
generic credential except in one instance.
When gss_destroying_context() calls rpc_call_null(), it passes
a specific credential that it needs to destroy.
In this case the RPC acts *on* the credential rather than
being authorized by it.
Rather than keying the access cache with 'struct rpc_cred',
use 'struct cred'. Then use cred_fscmp() to compare
credentials rather than comparing the raw pointer.
A benefit of this approach is that in the common case we avoid the
rpc_lookup_cred_nonblock() call which can be slow when the cred
In almost all cases the credential stored in rpc_message.rpc_cred
is a "generic" credential. One of the two expections is when an
AUTH_NULL credential is used such as for RPC ping requests.
To improve consistency, don't pass an explicit credential in
these cases, but instead pass NULL and set a
This is no longer used.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h |3 ---
net/sunrpc/auth_null.c |1 -
net/sunrpc/auth_unix.c |1 -
3 files changed, 5 deletions(-)
diff --git a/include/linux/sunrpc/auth.h b/include/linux/sunrpc/auth.h
index
Use the common 'struct cred' to pass credentials for readdir.
Signed-off-by: NeilBrown
---
fs/nfs/dir.c| 15 +--
fs/nfs/nfs3proc.c | 11 +--
fs/nfs/nfs4proc.c | 13 ++---
fs/nfs/proc.c | 11 +--
include/linux/nfs_fs.h
This is no longer used.
Signed-off-by: NeilBrown
---
include/linux/sunrpc/auth.h |6 -
net/sunrpc/Makefile |2
net/sunrpc/auth.c | 18
net/sunrpc/auth_generic.c | 199 ---
net/sunrpc/auth_null.c |2
5 files
NFS needs to know when a credential is about to expire so that
it can modify write-back behaviour to finish the write inside the
expiry time.
It currently uses functions in SUNRPC code which make use of a
fairly complex callback scheme and flags in the generic credientials.
As I am working to
The credential passed in rpc_message.rpc_cred is always a
generic credential except in one instance.
When gss_destroying_context() calls rpc_call_null(), it passes
a specific credential that it needs to destroy.
In this case the RPC acts *on* the credential rather than
being authorized by it.
201 - 300 of 614 matches
Mail list logo
