[rfc patch] mm, oom: fix unnecessary killing of additional processes

The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if it cannot reap an mm. This can happen for a variety of reasons, including: - the inability to grab mm->mmap_sem in a sufficient amount of time, - when the mm has blockable mmu notifiers that could cause the oom reaper

[rfc patch] mm, oom: fix unnecessary killing of additional processes

The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if it cannot reap an mm. This can happen for a variety of reasons, including: - the inability to grab mm->mmap_sem in a sufficient amount of time, - when the mm has blockable mmu notifiers that could cause the oom reaper

Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd

[...] >>> >>> * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain. >>> * @dev: Device to attach. >>> * @index: The index of the PM domain. >>> >>> This naming and description is a bit misleading, because really it is not >>> attaching the device that is passed, but creating a

Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd

[...] >>> >>> * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain. >>> * @dev: Device to attach. >>> * @index: The index of the PM domain. >>> >>> This naming and description is a bit misleading, because really it is not >>> attaching the device that is passed, but creating a

Re: [PATCH 0/2] mm->owner to mm->memcg fixes

On Thu, 24 May 2018 13:10:02 +0200 Michal Hocko wrote: > I would really prefer and appreciate a repost with all the fixes folded > in. [2/2] From: Andrew Morton Subject: mm/memcontrol.c: add mem_cgroup_from_task() as a local helper Factor out

Re: [PATCH 0/2] mm->owner to mm->memcg fixes

On Thu, 24 May 2018 13:10:02 +0200 Michal Hocko wrote: > I would really prefer and appreciate a repost with all the fixes folded > in. [2/2] From: Andrew Morton Subject: mm/memcontrol.c: add mem_cgroup_from_task() as a local helper Factor out some commonly-occurring code. Cc: "Eric W.

Re: [PATCH 0/2] mm->owner to mm->memcg fixes

On Thu, 24 May 2018 13:10:02 +0200 Michal Hocko wrote: > I would really prefer and appreciate a repost with all the fixes folded > in. [1/2] From: "Eric W. Biederman" Subject: memcg: replace mm->owner with mm->memcg Recently it was reported that

Re: [PATCH 0/2] mm->owner to mm->memcg fixes

On Thu, 24 May 2018 13:10:02 +0200 Michal Hocko wrote: > I would really prefer and appreciate a repost with all the fixes folded > in. [1/2] From: "Eric W. Biederman" Subject: memcg: replace mm->owner with mm->memcg Recently it was reported that mm_update_next_owner could get into cases

Re: write_lock_irq(_lock)

> Yeah, lemme put some details here: > > So we have three cases: > > Case #1 (from Will) > > P0: P1: P2: > > spin_lock() read_lock() > write_lock() > read_lock()

Re: write_lock_irq(_lock)

> Yeah, lemme put some details here: > > So we have three cases: > > Case #1 (from Will) > > P0: P1: P2: > > spin_lock() read_lock() > write_lock() > read_lock()

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 1:52 PM Nick Desaulniers wrote: > On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers > wrote: > > On Thu, May 24, 2018 at 11:59 AM wrote: > > > Issue 3: Let's face it, reading and writing the flags should be

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 1:52 PM Nick Desaulniers wrote: > On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers > wrote: > > On Thu, May 24, 2018 at 11:59 AM wrote: > > > Issue 3: Let's face it, reading and writing the flags should be > builtins, > > exactly because it has to do stack operations,

Re: [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains

On 24 May 2018 at 17:48, Jon Hunter wrote: > > On 18/05/18 11:31, Ulf Hansson wrote: >> >> The existing dev_pm_domain_attach() function, allows a single PM domain to >> be attached per device. To be able to support devices that are partitioned >> across multiple PM domains,

Re: [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains

On 24 May 2018 at 17:48, Jon Hunter wrote: > > On 18/05/18 11:31, Ulf Hansson wrote: >> >> The existing dev_pm_domain_attach() function, allows a single PM domain to >> be attached per device. To be able to support devices that are partitioned >> across multiple PM domains, let's introduce a new

Re: [PATCH v1 00/10] mm: online/offline 4MB chunks controlled by device driver

On 24.05.2018 16:22, Michal Hocko wrote: > I will go over the rest of the email later I just wanted to make this > point clear because I suspect we are talking past each other. It sounds like we are now talking about how to solve the problem. I like that :) > > On Thu 24-05-18 16:04:38, David

Re: [PATCH v1 00/10] mm: online/offline 4MB chunks controlled by device driver

On 24.05.2018 16:22, Michal Hocko wrote: > I will go over the rest of the email later I just wanted to make this > point clear because I suspect we are talking past each other. It sounds like we are now talking about how to solve the problem. I like that :) > > On Thu 24-05-18 16:04:38, David

Re: [PATCH v8 03/14] iommu/rockchip: Request irqs in rk_iommu_probe()

Hey Jeffy, Robin: Some odd issues to report here. On 23 March 2018 at 04:38, Jeffy Chen wrote: > Move request_irq to the end of rk_iommu_probe(). > > Suggested-by: Robin Murphy > Signed-off-by: Jeffy Chen > Acked-by:

Re: [PATCH v8 03/14] iommu/rockchip: Request irqs in rk_iommu_probe()

Hey Jeffy, Robin: Some odd issues to report here. On 23 March 2018 at 04:38, Jeffy Chen wrote: > Move request_irq to the end of rk_iommu_probe(). > > Suggested-by: Robin Murphy > Signed-off-by: Jeffy Chen > Acked-by: Robin Murphy > --- > > Changes in v8: None > Changes in v7: None > Changes

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

On Thu, May 24, 2018 at 2:00 PM, Greg Kroah-Hartman wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: >> Deferred probe will currently wait forever on dependent devices to probe, >> but sometimes a driver will never exist. It's also not always

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

On Thu, May 24, 2018 at 2:00 PM, Greg Kroah-Hartman wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: >> Deferred probe will currently wait forever on dependent devices to probe, >> but sometimes a driver will never exist. It's also not always critical for >> a driver to

Re: [PATCH -V2 -mm 1/4] mm, clear_huge_page: Move order algorithm into a separate function

On 05/23/2018 05:58 PM, Huang, Ying wrote: > From: Huang Ying > > In commit c79b57e462b5d ("mm: hugetlb: clear target sub-page last when > clearing huge page"), to keep the cache lines of the target subpage > hot, the order to clear the subpages in the huge page in >

Re: [PATCH -V2 -mm 1/4] mm, clear_huge_page: Move order algorithm into a separate function

On 05/23/2018 05:58 PM, Huang, Ying wrote: > From: Huang Ying > > In commit c79b57e462b5d ("mm: hugetlb: clear target sub-page last when > clearing huge page"), to keep the cache lines of the target subpage > hot, the order to clear the subpages in the huge page in > clear_huge_page() is changed

[PATCH] genirq: Synchronize only with single thread on free_irq()

When pciehp is converted to threaded IRQ handling, removal of unplugged devices below a PCIe hotplug port happens synchronously in the IRQ thread. Removal of devices typically entails a call to free_irq() by their drivers. If those devices share their IRQ with the hotplug port, free_irq()

[PATCH] genirq: Synchronize only with single thread on free_irq()

When pciehp is converted to threaded IRQ handling, removal of unplugged devices below a PCIe hotplug port happens synchronously in the IRQ thread. Removal of devices typically entails a call to free_irq() by their drivers. If those devices share their IRQ with the hotplug port, free_irq()

Re: [PATCH] doc: document scope NOFS, NOIO APIs

On Thu, 24 May 2018 13:43:41 +0200 Michal Hocko wrote: > From: Michal Hocko > > Although the api is documented in the source code Ted has pointed out > that there is no mention in the core-api Documentation and there are > people looking there to find

Re: [PATCH] doc: document scope NOFS, NOIO APIs

On Thu, 24 May 2018 13:43:41 +0200 Michal Hocko wrote: > From: Michal Hocko > > Although the api is documented in the source code Ted has pointed out > that there is no mention in the core-api Documentation and there are > people looking there to find answers how to use a specific API. > >

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers wrote: > On Thu, May 24, 2018 at 11:59 AM wrote: > > Issue 3: Let's face it, reading and writing the flags should be builtins, > exactly because it has to do stack operations, which really means the >

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers wrote: > On Thu, May 24, 2018 at 11:59 AM wrote: > > Issue 3: Let's face it, reading and writing the flags should be builtins, > exactly because it has to do stack operations, which really means the > compiler should be involved. > I'm happy to

[GIT PULL] Please pull RDMA subsystem changes

Hi Linus, Second pull request for -rc We haven't had quite the same rate of -rc patches this cycle, not much Syzkaller related stuff right now as the remaining bugs it has found require some kind of significant redesign to solve. The -next branch is also somewhat quieter than normal. This is

[GIT PULL] Please pull RDMA subsystem changes

Hi Linus, Second pull request for -rc We haven't had quite the same rate of -rc patches this cycle, not much Syzkaller related stuff right now as the remaining bugs it has found require some kind of significant redesign to solve. The -next branch is also somewhat quieter than normal. This is

Re: [PATCH v3 2/7] kexec: add call to LSM hook in original kexec_load syscall

Mimi Zohar writes: > In order for LSMs and IMA-appraisal to differentiate between the > original and new syscalls, both the original and new syscalls must call > an LSM hook. This patch adds a call to security_kernel_read_data() in > the original kexec syscall. Until

Re: [PATCH v3 2/7] kexec: add call to LSM hook in original kexec_load syscall

Mimi Zohar writes: > In order for LSMs and IMA-appraisal to differentiate between the > original and new syscalls, both the original and new syscalls must call > an LSM hook. This patch adds a call to security_kernel_read_data() in > the original kexec syscall. Until the lsm hook mess gets

Re: [PATCH v3 1/7] security: rename security_kernel_read_file() hook

I already nacked this approach because the two cases don't share a bit of code. When I looked closer it was even crazier. The way ima uses this hook and the post_load hook today is a travesty. The way the security_kernel_file_read and security_kernel_file_post_read are called today and are

Re: [PATCH v3 1/7] security: rename security_kernel_read_file() hook

I already nacked this approach because the two cases don't share a bit of code. When I looked closer it was even crazier. The way ima uses this hook and the post_load hook today is a travesty. The way the security_kernel_file_read and security_kernel_file_post_read are called today and are

Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm

On Thu, 24 May 2018 09:44:16 +0100 Suzuki K Poulose wrote: > On 14/05/18 10:45, Suzuki K Poulose wrote: > > On 10/05/18 00:31, Andrew Morton wrote: > >> On Fri,  4 May 2018 11:11:46 +0800 Jia He wrote: > >> > >>> In our armv8a server(QDF2400), I

Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm

On Thu, 24 May 2018 09:44:16 +0100 Suzuki K Poulose wrote: > On 14/05/18 10:45, Suzuki K Poulose wrote: > > On 10/05/18 00:31, Andrew Morton wrote: > >> On Fri,  4 May 2018 11:11:46 +0800 Jia He wrote: > >> > >>> In our armv8a server(QDF2400), I noticed lots of WARN_ON caused by > >>>

[PATCH 2/2] iio: 104-quad-8: Provide defines for magic numbers

This patch adds several register and bit defines to help improve the clarity of the code by cleaning up magic numbers throughout the driver source code. Signed-off-by: William Breathitt Gray --- drivers/iio/counter/104-quad-8.c | 86 ++-- 1

[PATCH 2/2] iio: 104-quad-8: Provide defines for magic numbers

This patch adds several register and bit defines to help improve the clarity of the code by cleaning up magic numbers throughout the driver source code. Signed-off-by: William Breathitt Gray --- drivers/iio/counter/104-quad-8.c | 86 ++-- 1 file changed, 60

[PATCH 0/2] Provide defines for 104-QUAD-8 magic numbers

Magic numbers can be difficult to understand, and at times hide bugs that would otherwise be obvious to readers of the source code. The first patch in this patchset provides a fix for an improperly selected magic number (an off-by-one error). The second patch adds defines to remove these magic

[PATCH 0/2] Provide defines for 104-QUAD-8 magic numbers

Magic numbers can be difficult to understand, and at times hide bugs that would otherwise be obvious to readers of the source code. The first patch in this patchset provides a fix for an improperly selected magic number (an off-by-one error). The second patch adds defines to remove these magic

[PATCH 1/2] iio: 104-quad-8: Fix off-by-one error in register selection

The reset flags operation is selected by bit 2 in the "Reset and Load Signals Decoders" register, not bit 1. Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8") Signed-off-by: William Breathitt Gray --- drivers/iio/counter/104-quad-8.c | 2

[PATCH 1/2] iio: 104-quad-8: Fix off-by-one error in register selection

The reset flags operation is selected by bit 2 in the "Reset and Load Signals Decoders" register, not bit 1. Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8") Signed-off-by: William Breathitt Gray --- drivers/iio/counter/104-quad-8.c | 2 +- 1 file changed, 1

Re: [PATCH v1 09/10] mm/memory_hotplug: teach offline_pages() to not try forever

On 24.05.2018 16:39, Michal Hocko wrote: > [I didn't really go through other patch but this one caught my eyes just > because of the similar request proposed yesterday] > > On Wed 23-05-18 17:11:50, David Hildenbrand wrote: > [...] >> @@ -1686,6 +1686,10 @@ static int __ref

Re: [PATCH v1 09/10] mm/memory_hotplug: teach offline_pages() to not try forever

On 24.05.2018 16:39, Michal Hocko wrote: > [I didn't really go through other patch but this one caught my eyes just > because of the similar request proposed yesterday] > > On Wed 23-05-18 17:11:50, David Hildenbrand wrote: > [...] >> @@ -1686,6 +1686,10 @@ static int __ref

Re: [PATCH 3/6] ASoC: ams_delta: use GPIO lookup table

On Wednesday, May 23, 2018 8:52:44 PM CEST Tony Lindgren wrote: > * Mark Brown [180521 10:07]: > > On Fri, May 18, 2018 at 11:09:51PM +0200, Janusz Krzysztofik wrote: > > > Now as the Amstrad Delta board provides GPIO lookup tables, switch from > > > GPIO numbers to GPIO

Re: [PATCH 3/6] ASoC: ams_delta: use GPIO lookup table

On Wednesday, May 23, 2018 8:52:44 PM CEST Tony Lindgren wrote: > * Mark Brown [180521 10:07]: > > On Fri, May 18, 2018 at 11:09:51PM +0200, Janusz Krzysztofik wrote: > > > Now as the Amstrad Delta board provides GPIO lookup tables, switch from > > > GPIO numbers to GPIO descriptors and use the

Re: [linux-sunxi] Re: [PATCH 05/15] drm/sun4i: Add TCON TOP driver

Hi, Dne četrtek, 24. maj 2018 ob 10:43:51 CEST je Maxime Ripard napisal(a): > Hi, > > On Mon, May 21, 2018 at 05:15:15PM +0200, Jernej Škrabec wrote: > > > > + /* > > > > +* Default register values might have some reserved bits set, which > > > > +* prevents TCON TOP from

Re: [linux-sunxi] Re: [PATCH 05/15] drm/sun4i: Add TCON TOP driver

Hi, Dne četrtek, 24. maj 2018 ob 10:43:51 CEST je Maxime Ripard napisal(a): > Hi, > > On Mon, May 21, 2018 at 05:15:15PM +0200, Jernej Škrabec wrote: > > > > + /* > > > > +* Default register values might have some reserved bits set, which > > > > +* prevents TCON TOP from

Re: [PATCH 4.4 00/92] 4.4.133-stable review

> > kernel: 4.4.133-rc1 > > git repo: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > git branch: linux-4.4.y > > git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 > > git describe: v4.4.132-93-g915a3d7cdea9 > > Test details: > >

Re: [PATCH 4.4 00/92] 4.4.133-stable review

> > kernel: 4.4.133-rc1 > > git repo: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > git branch: linux-4.4.y > > git commit: 915a3d7cdea9daa9e9fb6b855f10c1312e6910c4 > > git describe: v4.4.132-93-g915a3d7cdea9 > > Test details: > >

Re: [PATCH] gpu: drm: drm_vm: Adding new typedef vm_fault_t

On Wed, May 16, 2018 at 10:09 AM, Souptick Joarder wrote: > On Thu, May 10, 2018 at 7:12 PM, Souptick Joarder > wrote: >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT

Re: [PATCH] gpu: drm: drm_vm: Adding new typedef vm_fault_t

On Wed, May 16, 2018 at 10:09 AM, Souptick Joarder wrote: > On Thu, May 10, 2018 at 7:12 PM, Souptick Joarder > wrote: >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT value rather than an errno. Once all instances

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 11:59 AM wrote: > Ok, this is the *second* thing about LLVM-originated bug reports that drives me batty. When you *do* identify a real problem, you propose a paper over and/or talk about it as an LLVM issue and don't consider the often far bigger picture.

Re: [clang] stack protector and f1f029c7bf

On Thu, May 24, 2018 at 11:59 AM wrote: > Ok, this is the *second* thing about LLVM-originated bug reports that drives me batty. When you *do* identify a real problem, you propose a paper over and/or talk about it as an LLVM issue and don't consider the often far bigger picture. Considering the

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

On Thu, May 24, 2018 at 1:18 PM, Mark Brown wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning >> -EPROBE_DEFER. They may

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

On Thu, May 24, 2018 at 1:18 PM, Mark Brown wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning >> -EPROBE_DEFER. They may use additional

Re: [PATCH] selftests: intel_pstate: Fixes for the testing script for Intel P-State driver

On Thu, May 24, 2018 at 10:11 PM, Shuah Khan wrote: > The commit log doesn't match the commit summary. Please rephrase both the > commit summary and log to indicate why this fix is necessary. i will work related to that > Odd. I don't see your patch posted on the

Re: [PATCH] selftests: intel_pstate: Fixes for the testing script for Intel P-State driver

On Thu, May 24, 2018 at 10:11 PM, Shuah Khan wrote: > The commit log doesn't match the commit summary. Please rephrase both the > commit summary and log to indicate why this fix is necessary. i will work related to that > Odd. I don't see your patch posted on the linux-kselftest patchwork and

[PATCH] gpu: Consistently use octal not symbolic permissions

There is currently a mixture of octal and symbolic permissions uses in files in drivers/gpu/drm and one file in drivers/gpu. There are ~270 existing octal uses and ~115 S_ uses. Convert all the S_ symbolic permissions to their octal equivalents as using octal and not symbolic permissions is

[PATCH] gpu: Consistently use octal not symbolic permissions

There is currently a mixture of octal and symbolic permissions uses in files in drivers/gpu/drm and one file in drivers/gpu. There are ~270 existing octal uses and ~115 S_ uses. Convert all the S_ symbolic permissions to their octal equivalents as using octal and not symbolic permissions is

Re: [PATCH] leds: class: ensure workqueue is initialized before setting brightness

Hi Luis, Thank you for the patch. On 05/24/2018 12:22 AM, Luis Henriques wrote: An application can try to set brightness before all the initialization is done, in particular before the workqueue is initialized with the call to led_init_core(). Here's a WARNING easy to trigger: [ 36.780813]

[PATCH] fuse: fix NULL dereference when new_inode() fails

fuse_ctl_remove_conn() dereferences d_inode(fc->ctl_dentry[i]). If fuse_ctl_add_dentry() failed to allocate the inode then this field is NULL and it's not safe to call fuse_ctl_remove_conn(). This patch frees partially initialized dentries in the fuse_ctl_add_dentry() error case to solve the

Re: [PATCH] leds: class: ensure workqueue is initialized before setting brightness

Hi Luis, Thank you for the patch. On 05/24/2018 12:22 AM, Luis Henriques wrote: An application can try to set brightness before all the initialization is done, in particular before the workqueue is initialized with the call to led_init_core(). Here's a WARNING easy to trigger: [ 36.780813]

[PATCH] fuse: fix NULL dereference when new_inode() fails

fuse_ctl_remove_conn() dereferences d_inode(fc->ctl_dentry[i]). If fuse_ctl_add_dentry() failed to allocate the inode then this field is NULL and it's not safe to call fuse_ctl_remove_conn(). This patch frees partially initialized dentries in the fuse_ctl_add_dentry() error case to solve the

Re: [PATCH 2/2] i2c: robotfuzz-osif: drop pointless test

On Wed, May 09, 2018 at 09:46:58PM +0200, Peter Rosin wrote: > In the for-loop test, ret will be either 0 or 1. So, the > comparison is pointless. Drop it, and drop the initializer > which is then also pointless. > > Signed-off-by: Peter Rosin Applied to for-next, thanks!

[PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

Update support for the UV kernel to accommodate Intel BIOS changes in NVDIMM alignment, which caused UV BIOS to align the memory boundaries on different blocks than the previous UV standard of 2GB. Background: Since 2009 the UV arch dependent support has used 2GB as the memory block size mainly

[PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

Update support for the UV kernel to accommodate Intel BIOS changes in NVDIMM alignment, which caused UV BIOS to align the memory boundaries on different blocks than the previous UV standard of 2GB. Background: Since 2009 the UV arch dependent support has used 2GB as the memory block size mainly

Re: [PATCH 2/2] i2c: robotfuzz-osif: drop pointless test

On Wed, May 09, 2018 at 09:46:58PM +0200, Peter Rosin wrote: > In the for-loop test, ret will be either 0 or 1. So, the > comparison is pointless. Drop it, and drop the initializer > which is then also pointless. > > Signed-off-by: Peter Rosin Applied to for-next, thanks! Reading that

[PATCH 1/3] x86/platform/UV: Add adjustable set memory block size function

Add a new function to "adjust" the current fixed UV memory block size of 2GB so it can be changed to a different physical boundary. This is out of necessity so arch dependent code can accommodate specific BIOS requirements which can align these new PMEM modules at less than the default

[PATCH 1/3] x86/platform/UV: Add adjustable set memory block size function

Add a new function to "adjust" the current fixed UV memory block size of 2GB so it can be changed to a different physical boundary. This is out of necessity so arch dependent code can accommodate specific BIOS requirements which can align these new PMEM modules at less than the default

Re: uImage target support on arm64

On Thu, May 24, 2018 at 10:34 PM, Baruch Siach wrote: > Hi Ramon, > > On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote: >> I've noticed that it's not supported. >> Is it on purpose ? > > Yes. The 32bit load address in the uImage header in pretty limited when >

Re: uImage target support on arm64

On Thu, May 24, 2018 at 10:34 PM, Baruch Siach wrote: > Hi Ramon, > > On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote: >> I've noticed that it's not supported. >> Is it on purpose ? > > Yes. The 32bit load address in the uImage header in pretty limited when > applied to 64bit ARM64.

[PATCH 2/3] x86/platform/UV: Use new set memory block size function

Add a call to the new function to "adjust" the current fixed UV memory block size of 2GB so it can be changed to a different physical boundary. This accommodates changes in the Intel BIOS, and therefore UV BIOS, which now can align boundaries different than the previous UV standard of 2GB. It

[PATCH 2/3] x86/platform/UV: Use new set memory block size function

Add a call to the new function to "adjust" the current fixed UV memory block size of 2GB so it can be changed to a different physical boundary. This accommodates changes in the Intel BIOS, and therefore UV BIOS, which now can align boundaries different than the previous UV standard of 2GB. It

[PATCH 3/3] x86/platform/UV: Add kernel parameter to set memory block size

Add a kernel parameter that allows setting UV memory block size. This is to provide an adjustment for new forms of PMEM and other DIMM memory that might require alignment restrictions other than scanning the global address table for the required minimum alignment. The value set will be further

[PATCH 3/3] x86/platform/UV: Add kernel parameter to set memory block size

Add a kernel parameter that allows setting UV memory block size. This is to provide an adjustment for new forms of PMEM and other DIMM memory that might require alignment restrictions other than scanning the global address table for the required minimum alignment. The value set will be further

Re: [PATCH 1/2] i2c: robotfuzz-osif: remove pointless local variable

On Wed, May 09, 2018 at 09:46:57PM +0200, Peter Rosin wrote: > Just use the value directly instead of assigning it to a > variable first. And then drop the unused variable. > > Signed-off-by: Peter Rosin Applied to for-next, thanks! signature.asc Description: PGP signature

Re: [PATCH 1/2] i2c: robotfuzz-osif: remove pointless local variable

On Wed, May 09, 2018 at 09:46:57PM +0200, Peter Rosin wrote: > Just use the value directly instead of assigning it to a > variable first. And then drop the unused variable. > > Signed-off-by: Peter Rosin Applied to for-next, thanks! signature.asc Description: PGP signature

[PATCH 0/8] IMA: work on audit records produced by IMA

This series of patches cleans up some usages of the audit subsystem's API by IMA and extends the audit subsystem's API with API calls for adding new fields to the audit_buffer. Besides that we extend the existing audit records created while parsing IMA policy rules with fields that are common for

[PATCH 0/8] IMA: work on audit records produced by IMA

This series of patches cleans up some usages of the audit subsystem's API by IMA and extends the audit subsystem's API with API calls for adding new fields to the audit_buffer. Besides that we extend the existing audit records created while parsing IMA policy rules with fields that are common for

[PATCH 4/8] audit: Allow others to call audit_log_d_path_exe()

Add the prototype for audit_log_d_path_exe() so that it can be called by IMA later in this series. Signed-off-by: Stefan Berger Reviewed-by: Mimi Zohar --- include/linux/audit.h | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 4/8] audit: Allow others to call audit_log_d_path_exe()

Add the prototype for audit_log_d_path_exe() so that it can be called by IMA later in this series. Signed-off-by: Stefan Berger Reviewed-by: Mimi Zohar --- include/linux/audit.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/audit.h b/include/linux/audit.h index

[PATCH 7/8] ima: Do not audit if CONFIG_INTEGRITY_AUDIT is not set

If Integrity is not auditing, IMA shouldn't audit, either. Signed-off-by: Stefan Berger --- security/integrity/ima/Kconfig | 1 + security/integrity/ima/ima_policy.c | 6 +- security/integrity/integrity.h | 10 ++ 3 files changed, 16

[PATCH 8/8] ima: Differentiate auditing policy rules from "audit" actions

The AUDIT_INTEGRITY_RULE is used for auditing IMA policy rules and the IMA "audit" policy action. This patch defines AUDIT_INTEGRITY_POLICY_RULE to reflect the IMA policy rules. With this change we now call integrity_audit_msg_common() to get common integrity auditing fields. This now produces

[PATCH 7/8] ima: Do not audit if CONFIG_INTEGRITY_AUDIT is not set

If Integrity is not auditing, IMA shouldn't audit, either. Signed-off-by: Stefan Berger --- security/integrity/ima/Kconfig | 1 + security/integrity/ima/ima_policy.c | 6 +- security/integrity/integrity.h | 10 ++ 3 files changed, 16 insertions(+), 1 deletion(-) diff

[PATCH 8/8] ima: Differentiate auditing policy rules from "audit" actions

The AUDIT_INTEGRITY_RULE is used for auditing IMA policy rules and the IMA "audit" policy action. This patch defines AUDIT_INTEGRITY_POLICY_RULE to reflect the IMA policy rules. With this change we now call integrity_audit_msg_common() to get common integrity auditing fields. This now produces

[PATCH 5/8] integrity: Add exe= and tty= before res= to integrity audits

Use the new public audit functions to add the exe= and tty= parts to the integrity audit records. We place them before res=. Signed-off-by: Stefan Berger Suggested-by: Steve Grubb --- security/integrity/integrity_audit.c | 2 ++ 1 file changed, 2

[PATCH 5/8] integrity: Add exe= and tty= before res= to integrity audits

Use the new public audit functions to add the exe= and tty= parts to the integrity audit records. We place them before res=. Signed-off-by: Stefan Berger Suggested-by: Steve Grubb --- security/integrity/integrity_audit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 6/8] integrity: Factor out common part of integrity_audit_msg()

Factor out a common part of integrity_audit_msg() that others can also call. Signed-off-by: Stefan Berger --- security/integrity/integrity.h | 16 security/integrity/integrity_audit.c | 24 2 files changed, 32

[PATCH 6/8] integrity: Factor out common part of integrity_audit_msg()

Factor out a common part of integrity_audit_msg() that others can also call. Signed-off-by: Stefan Berger --- security/integrity/integrity.h | 16 security/integrity/integrity_audit.c | 24 2 files changed, 32 insertions(+), 8 deletions(-) diff

[PATCH 1/8] ima: Call audit_log_string() rather than logging it untrusted

The parameters passed to this logging function are all provided by a privileged user and therefore we can call audit_log_string() rather than audit_log_untrustedstring(). Signed-off-by: Stefan Berger Suggested-by: Steve Grubb ---

[PATCH 1/8] ima: Call audit_log_string() rather than logging it untrusted

The parameters passed to this logging function are all provided by a privileged user and therefore we can call audit_log_string() rather than audit_log_untrustedstring(). Signed-off-by: Stefan Berger Suggested-by: Steve Grubb --- security/integrity/ima/ima_policy.c | 2 +- 1 file changed, 1

[PATCH 2/8] ima: Use audit_log_format() rather than audit_log_string()

Remove the usage of audit_log_string() and replace it with audit_log_format(). Signed-off-by: Stefan Berger Suggested-by: Steve Grubb Reviewed-by: Mimi Zohar --- security/integrity/ima/ima_policy.c | 3 +--

[PATCH 2/8] ima: Use audit_log_format() rather than audit_log_string()

Remove the usage of audit_log_string() and replace it with audit_log_format(). Signed-off-by: Stefan Berger Suggested-by: Steve Grubb Reviewed-by: Mimi Zohar --- security/integrity/ima/ima_policy.c | 3 +-- security/integrity/integrity_audit.c | 6 +- 2 files changed, 2 insertions(+), 7

[PATCH 3/8] audit: Implement audit_log_tty()

Implement audit_log_tty() so that IMA can add tty= to its audit records. Signed-off-by: Stefan Berger --- include/linux/audit.h | 5 + kernel/audit.c| 8 2 files changed, 13 insertions(+) diff --git a/include/linux/audit.h

[PATCH 3/8] audit: Implement audit_log_tty()

Implement audit_log_tty() so that IMA can add tty= to its audit records. Signed-off-by: Stefan Berger --- include/linux/audit.h | 5 + kernel/audit.c| 8 2 files changed, 13 insertions(+) diff --git a/include/linux/audit.h b/include/linux/audit.h index

Re: [reset-control] How to initialize hardware state with the shared reset line?

Hi Philipp, On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel wrote: > Hi Martin, > > On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote: >> Hello, >> >> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada >> wrote: >> > Hi. >> > >> >

Re: [reset-control] How to initialize hardware state with the shared reset line?

Hi Philipp, On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel wrote: > Hi Martin, > > On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote: >> Hello, >> >> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada >> wrote: >> > Hi. >> > >> > >> > 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl >> >

Re: [PATCH] rtlwifi: remove duplicate code

Hi Joe, On 05/24/2018 02:24 PM, Joe Perches wrote: On Thu, 2018-05-24 at 13:54 -0500, Gustavo A. R. Silva wrote: Remove and refactor some code in order to avoid having identical code for different branches. True and nice tool and patch submittal thanks. Notice that the logic has been there

Re: [PATCH] rtlwifi: remove duplicate code

Hi Joe, On 05/24/2018 02:24 PM, Joe Perches wrote: On Thu, 2018-05-24 at 13:54 -0500, Gustavo A. R. Silva wrote: Remove and refactor some code in order to avoid having identical code for different branches. True and nice tool and patch submittal thanks. Notice that the logic has been there

<    1   2   3   4   5   6   7   8   9   10   >