Hello,
syzbot found the following crash on:
HEAD commit:c307aaf3eb47 Merge tag 'iommu-fixes-v4.19-rc5' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13810df140
kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
Hello,
syzbot found the following crash on:
HEAD commit:c307aaf3eb47 Merge tag 'iommu-fixes-v4.19-rc5' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13810df140
kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
On Wed, 26 Sep 2018, Rob Herring wrote:
> On Mon, Sep 17, 2018 at 04:33:22PM +0100, Charles Keepax wrote:
> > Signed-off-by: Charles Keepax
> > ---
> > Documentation/devicetree/bindings/mfd/arizona.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Applied.
Probably won't do
On Wed, 26 Sep 2018, Rob Herring wrote:
> On Mon, Sep 17, 2018 at 04:33:22PM +0100, Charles Keepax wrote:
> > Signed-off-by: Charles Keepax
> > ---
> > Documentation/devicetree/bindings/mfd/arizona.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Applied.
Probably won't do
> > + case MBOCHS_EDID_REGION_INDEX:
> > + ext->base.argsz = sizeof(*ext);
> > + ext->base.offset = MBOCHS_EDID_OFFSET;
> > + ext->base.size = MBOCHS_EDID_SIZE;
> > + ext->base.flags = (VFIO_REGION_INFO_FLAG_READ |
> > +
> > + case MBOCHS_EDID_REGION_INDEX:
> > + ext->base.argsz = sizeof(*ext);
> > + ext->base.offset = MBOCHS_EDID_OFFSET;
> > + ext->base.size = MBOCHS_EDID_SIZE;
> > + ext->base.flags = (VFIO_REGION_INFO_FLAG_READ |
> > +
From: John Hubbard
For code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(),
instead of put_page().
This prepares for eventually fixing the problem described
in [1], and is following a plan listed in [2].
[1] https://lwn.net/Articles/753027/ : "The
From: John Hubbard
For code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(),
instead of put_page().
This prepares for eventually fixing the problem described
in [1], and is following a plan listed in [2].
[1] https://lwn.net/Articles/753027/ : "The
From: John Hubbard
Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().
Also adds release_user_pages(), a drop-in replacement for
release_pages(). This is intended to be
From: John Hubbard
Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().
Also adds release_user_pages(), a drop-in replacement for
release_pages(). This is intended to be
From: John Hubbard
Hi,
This short series prepares for eventually fixing the problem described
in [1], and is following a plan listed in [2].
I'd like to get the first two patches into the -mm tree.
Patch 1, although not technically critical to do now, is still nice to have,
because it's
From: John Hubbard
An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.
In preparation for that, consolidate the error handling for
__get_user_pages(). This provides a single location (the "out:" label)
for operating on the collected set
From: John Hubbard
For code that retains pages via get_user_pages*(),
release those pages via the new release_user_pages(),
instead of calling put_page().
This prepares for eventually fixing the problem described
in [1], and is following a plan listed in [2].
[1]
From: John Hubbard
Hi,
This short series prepares for eventually fixing the problem described
in [1], and is following a plan listed in [2].
I'd like to get the first two patches into the -mm tree.
Patch 1, although not technically critical to do now, is still nice to have,
because it's
From: John Hubbard
An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.
In preparation for that, consolidate the error handling for
__get_user_pages(). This provides a single location (the "out:" label)
for operating on the collected set
From: John Hubbard
For code that retains pages via get_user_pages*(),
release those pages via the new release_user_pages(),
instead of calling put_page().
This prepares for eventually fixing the problem described
in [1], and is following a plan listed in [2].
[1]
mmu_gather_tlb no longer exist. Replace with mmu_table_batch.
CC: triv...@kernel.org
Signed-off-by: Fengguang Wu
---
mm/gup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index fc5f98069f4e..69194043ddd4 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@
mmu_gather_tlb no longer exist. Replace with mmu_table_batch.
CC: triv...@kernel.org
Signed-off-by: Fengguang Wu
---
mm/gup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index fc5f98069f4e..69194043ddd4 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@
Hi all,
News: there will be no linux-next release on Monday
Changes since 20180927:
Dropped trees: xarray, ida (temporarily)
The rdma tree gained a conflict against Linus' tree.
The userns tree gained a conflict against the arm64 tree.
Non-merge commits (relative to Linus' tree): 6651
6736
Hi all,
News: there will be no linux-next release on Monday
Changes since 20180927:
Dropped trees: xarray, ida (temporarily)
The rdma tree gained a conflict against Linus' tree.
The userns tree gained a conflict against the arm64 tree.
Non-merge commits (relative to Linus' tree): 6651
6736
On Wednesday 26 September 2018 10:57 PM, Tony Lindgren wrote:
> * Vignesh R [180924 22:25]:
>> Bit positions of PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE and
>> PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE in CTRL_CORE_SMA_SW_7 are
>> incorrectly documented in the TRM. In fact, the bit positions are
>>
On Wednesday 26 September 2018 10:57 PM, Tony Lindgren wrote:
> * Vignesh R [180924 22:25]:
>> Bit positions of PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE and
>> PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE in CTRL_CORE_SMA_SW_7 are
>> incorrectly documented in the TRM. In fact, the bit positions are
>>
On Wednesday 26 September 2018 08:14 PM, Peter Rosin wrote:
> On 2018-09-26 13:57, Vignesh R wrote:
>> AM654 SoCs have similar I2C IP as OMAP SoCs. Add new compatible to
>> handle AM654 SoCs.
>>
>> Signed-off-by: Vignesh R
>> ---
>> Documentation/devicetree/bindings/i2c/i2c-omap.txt | 3 ++-
On Wednesday 26 September 2018 08:14 PM, Peter Rosin wrote:
> On 2018-09-26 13:57, Vignesh R wrote:
>> AM654 SoCs have similar I2C IP as OMAP SoCs. Add new compatible to
>> handle AM654 SoCs.
>>
>> Signed-off-by: Vignesh R
>> ---
>> Documentation/devicetree/bindings/i2c/i2c-omap.txt | 3 ++-
Couple of patches to enable i2c-omap driver to be used with TI's new
AM654 platforms.
Vignesh R (2):
dt-bindings: i2c-omap: Add new compatible for AM654 SoCs
i2c: busses: Kconfig: Enable I2C_OMAP for ARCH_K3
Documentation/devicetree/bindings/i2c/i2c-omap.txt | 8 ++--
Allow I2C_OMAP to be built for K3 platforms.
Signed-off-by: Vignesh R
---
v2: No changes
drivers/i2c/busses/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 451d4ae50e66..ac4b09642f63 100644
---
AM654 SoCs have same I2C IP as OMAP SoCs. Add new compatible to
handle AM654 SoCs. While at that reformat the existing compatible list
for older SoCs to list one valid compatible per line.
Signed-off-by: Vignesh R
---
v2: Reformat compatible existing compatible list.
Couple of patches to enable i2c-omap driver to be used with TI's new
AM654 platforms.
Vignesh R (2):
dt-bindings: i2c-omap: Add new compatible for AM654 SoCs
i2c: busses: Kconfig: Enable I2C_OMAP for ARCH_K3
Documentation/devicetree/bindings/i2c/i2c-omap.txt | 8 ++--
Allow I2C_OMAP to be built for K3 platforms.
Signed-off-by: Vignesh R
---
v2: No changes
drivers/i2c/busses/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 451d4ae50e66..ac4b09642f63 100644
---
AM654 SoCs have same I2C IP as OMAP SoCs. Add new compatible to
handle AM654 SoCs. While at that reformat the existing compatible list
for older SoCs to list one valid compatible per line.
Signed-off-by: Vignesh R
---
v2: Reformat compatible existing compatible list.
On Thu, Sep 27, 2018 at 07:20:50PM -0700, Kees Cook wrote:
> On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> > On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> >> an arbitrary struct files_struct, not
On Thu, Sep 27, 2018 at 07:20:50PM -0700, Kees Cook wrote:
> On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> > On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> >> an arbitrary struct files_struct, not
Hi Ravi,
> On Sep 27, 2018, at 9:33 PM, Ravi Bangoria
> wrote:
>
> Hi Song,
>
> On 09/25/2018 03:55 AM, Song Liu wrote:
>> This patch tries to enable PMU sharing. To make perf event scheduling
>> fast, we use special data structures.
>>
>> An array of "struct perf_event_dup" is added to the
Hi Ravi,
> On Sep 27, 2018, at 9:33 PM, Ravi Bangoria
> wrote:
>
> Hi Song,
>
> On 09/25/2018 03:55 AM, Song Liu wrote:
>> This patch tries to enable PMU sharing. To make perf event scheduling
>> fast, we use special data structures.
>>
>> An array of "struct perf_event_dup" is added to the
On Thu, Sep 27, 2018 at 05:00:30PM -0300, Rafael David Tinoco wrote:
> On 9/27/18 6:02 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.11 release.
> > There are 88 patches in this series, all will be posted as a response
> > to this one. If anyone has
On Thu, Sep 27, 2018 at 05:00:30PM -0300, Rafael David Tinoco wrote:
> On 9/27/18 6:02 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.11 release.
> > There are 88 patches in this series, all will be posted as a response
> > to this one. If anyone has
On Thu, Sep 27, 2018 at 02:53:12PM -0700, Guenter Roeck wrote:
> On Thu, Sep 27, 2018 at 11:02:41AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.11 release.
> > There are 88 patches in this series, all will be posted as a response
> > to this one.
On Thu, Sep 27, 2018 at 02:09:08PM -0600, Shuah Khan wrote:
> On 09/27/2018 03:02 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.11 release.
> > There are 88 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Thu, Sep 27, 2018 at 02:53:12PM -0700, Guenter Roeck wrote:
> On Thu, Sep 27, 2018 at 11:02:41AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.11 release.
> > There are 88 patches in this series, all will be posted as a response
> > to this one.
On Thu, Sep 27, 2018 at 02:09:08PM -0600, Shuah Khan wrote:
> On 09/27/2018 03:02 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.11 release.
> > There are 88 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Thu, Sep 27, 2018 at 10:45:30PM +0100, Sudip Mukherjee wrote:
> Hi Greg,
>
> On Thu, Sep 27, 2018 at 9:56 PM, Sudip Mukherjee
> wrote:
> > Hi Greg,
> >
> > On Thu, Sep 27, 2018 at 10:03 AM, Greg Kroah-Hartman
> > wrote:
> >> This is the start of the stable review cycle for the 4.14.73
On Thu, Sep 27, 2018 at 10:45:30PM +0100, Sudip Mukherjee wrote:
> Hi Greg,
>
> On Thu, Sep 27, 2018 at 9:56 PM, Sudip Mukherjee
> wrote:
> > Hi Greg,
> >
> > On Thu, Sep 27, 2018 at 10:03 AM, Greg Kroah-Hartman
> > wrote:
> >> This is the start of the stable review cycle for the 4.14.73
futex_detect_cmpxchg() checks whether cmpxchg is available by trying
it on the NULL pointer and seeing what the error code is (EFAULT vs
ENOSYS). This happens with KERNEL_DS set, which is impolite: while
the NULL *user* pointer is definitely invalid when there is no user
program running, the NULL
futex_detect_cmpxchg() checks whether cmpxchg is available by trying
it on the NULL pointer and seeing what the error code is (EFAULT vs
ENOSYS). This happens with KERNEL_DS set, which is impolite: while
the NULL *user* pointer is definitely invalid when there is no user
program running, the NULL
Hi Song,
On 09/25/2018 03:55 AM, Song Liu wrote:
> This patch tries to enable PMU sharing. To make perf event scheduling
> fast, we use special data structures.
>
> An array of "struct perf_event_dup" is added to the perf_event_context,
> to remember all the duplicated events under this ctx. All
Hi Song,
On 09/25/2018 03:55 AM, Song Liu wrote:
> This patch tries to enable PMU sharing. To make perf event scheduling
> fast, we use special data structures.
>
> An array of "struct perf_event_dup" is added to the perf_event_context,
> to remember all the duplicated events under this ctx. All
Yahoo!©
We are delighted to inform you that you were drawn a winner of (USD
$5,005,000.00)
in our 2018 Yahoo (email) lottery. To file for claim please contact below our
(claim officer)
__
Sir. Warren Vandall
(Claims Officer)
Asian Regional Sector
Yahoo!©
We are delighted to inform you that you were drawn a winner of (USD
$5,005,000.00)
in our 2018 Yahoo (email) lottery. To file for claim please contact below our
(claim officer)
__
Sir. Warren Vandall
(Claims Officer)
Asian Regional Sector
NAND devices need additional data area (OOB) for error correction,
but it is also used for Bad Block Marker (BBM). In many cases, the
first byte in OOB is used for BBM, but the location actually depends
on chip vendors. The NAND controller should preserve the precious
BBM to keep track of bad
NAND devices need additional data area (OOB) for error correction,
but it is also used for Bad Block Marker (BBM). In many cases, the
first byte in OOB is used for BBM, but the location actually depends
on chip vendors. The NAND controller should preserve the precious
BBM to keep track of bad
freedomfromr...@aaathats3as.com :
> As has been stated in easily accessible terms elsewhere:
> "Most courts hold that simple, non-exclusive licenses with unspecified
> durations that are silent on revocability are revocable at will. This means
> that the licensor may terminate the license at any
freedomfromr...@aaathats3as.com :
> As has been stated in easily accessible terms elsewhere:
> "Most courts hold that simple, non-exclusive licenses with unspecified
> durations that are silent on revocability are revocable at will. This means
> that the licensor may terminate the license at any
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in:
arch/arm64/kernel/traps.c
between commit:
8a60419d3676 ("arm64: force_signal_inject: WARN if called from kernel
context")
from the arm64 tree and commit:
6fa998e83ef9 ("signal/arm64: Push siginfo generation into
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in:
arch/arm64/kernel/traps.c
between commit:
8a60419d3676 ("arm64: force_signal_inject: WARN if called from kernel
context")
from the arm64 tree and commit:
6fa998e83ef9 ("signal/arm64: Push siginfo generation into
As has been stated in easily accessible terms elsewhere:
"Most courts hold that simple, non-exclusive licenses with unspecified
durations that are silent on revocability are revocable at will. This
means that the licensor may terminate the license at any time, with or
without cause." +
As has been stated in easily accessible terms elsewhere:
"Most courts hold that simple, non-exclusive licenses with unspecified
durations that are silent on revocability are revocable at will. This
means that the licensor may terminate the license at any time, with or
without cause." +
Gnu GPL version 2, section 0:
"Each licensee is addressed as "you". "
The "you" is not referring to the licensor (copyright owner). It is
referring to the licensees and then future
sub-licensees/additional-licensees receiving the work from said previous
licensee.
It is independently clear
Gnu GPL version 2, section 0:
"Each licensee is addressed as "you". "
The "you" is not referring to the licensor (copyright owner). It is
referring to the licensees and then future
sub-licensees/additional-licensees receiving the work from said previous
licensee.
It is independently clear
On Thu 27 Sep 14:36 PDT 2018, Colin King wrote:
> From: Colin Ian King
>
> Currently a failed allocation of channel->name leads to an
> immediate return without freeing channel. Fix this by setting
> ret to -ENOMEM and jumping to an exit path that kfree's channel.
>
> Detected by CoverityScan,
On Thu 27 Sep 14:36 PDT 2018, Colin King wrote:
> From: Colin Ian King
>
> Currently a failed allocation of channel->name leads to an
> immediate return without freeing channel. Fix this by setting
> ret to -ENOMEM and jumping to an exit path that kfree's channel.
>
> Detected by CoverityScan,
On Thu, Sep 27, 2018 at 05:55:43PM -0700, Nick Desaulniers wrote:
> On Thu, Sep 27, 2018 at 3:58 PM Jason Gunthorpe wrote:
> >
> > On Thu, Sep 27, 2018 at 03:42:24PM -0700, Nick Desaulniers wrote:
> > > On Thu, Sep 27, 2018 at 3:33 PM Bart Van Assche
> > > wrote:
> > > >
> > > > On Thu,
On Thu, Sep 27, 2018 at 05:55:43PM -0700, Nick Desaulniers wrote:
> On Thu, Sep 27, 2018 at 3:58 PM Jason Gunthorpe wrote:
> >
> > On Thu, Sep 27, 2018 at 03:42:24PM -0700, Nick Desaulniers wrote:
> > > On Thu, Sep 27, 2018 at 3:33 PM Bart Van Assche
> > > wrote:
> > > >
> > > > On Thu,
If a cache has an unknown type because neither the hardware nor the
firmware told us, an entry in the sysfs tree will be made, but the type
file will not be present. lscpu depends on the type file being present
for every entry, and will error out without printing system information
if lscpu
The type of a cache might not be specified by architectural mechanisms (ie
system registers), but its type might be specified in the PPTT. In this
case, we should populate the type of the cache, rather than leave it
undefined.
This fixes the issue where the cacheinfo driver will not populate
The ARM Architecture Reference Manual allows for caches to be "invisible" and
thus not specified in the system registers under some scenarios such as if the
cache cannot be managed by set/way operations.
However, such caches may be specified in the ACPI PPTT table for workload
The type of a cache might not be specified by architectural mechanisms (ie
system registers), but its type might be specified in the PPTT. In this
case, we should populate the type of the cache, rather than leave it
undefined.
This fixes the issue where the cacheinfo driver will not populate
The ARM Architecture Reference Manual allows for caches to be "invisible" and
thus not specified in the system registers under some scenarios such as if the
cache cannot be managed by set/way operations.
However, such caches may be specified in the ACPI PPTT table for workload
If a cache has an unknown type because neither the hardware nor the
firmware told us, an entry in the sysfs tree will be made, but the type
file will not be present. lscpu depends on the type file being present
for every entry, and will error out without printing system information
if lscpu
On 09/27/18 at 04:31pm, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> Add warning message if the padding size for KASLR,
> rand_mem_physical_padding, is not enough. The message also
> says the suitable padding size.
>
> Signed-off-by: Masayoshi Mizuma
> ---
>
On 09/27/18 at 04:31pm, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> Add warning message if the padding size for KASLR,
> rand_mem_physical_padding, is not enough. The message also
> says the suitable padding size.
>
> Signed-off-by: Masayoshi Mizuma
> ---
>
On Fri, Sep 28, 2018 at 4:20 AM Kees Cook wrote:
> On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> > On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> >> an arbitrary struct files_struct, not just
On Fri, Sep 28, 2018 at 4:20 AM Kees Cook wrote:
> On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> > On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> Similar to fd_install/__fd_install, we want to be able to replace an fd of
> >> an arbitrary struct files_struct, not just
On 9/27/18 11:53 PM, Eddie Chapman wrote:
On 27/09/18 16:23, Coly Li wrote:
On 9/27/18 9:45 PM, guoju wrote:
After write SSD completed, bcache schedule journal_write work to
system_wq, that is a public workqueue in system, without WQ_MEM_RECLAIM
flag. system_wq is also a bound wq, and there
On 9/27/18 11:53 PM, Eddie Chapman wrote:
On 27/09/18 16:23, Coly Li wrote:
On 9/27/18 9:45 PM, guoju wrote:
After write SSD completed, bcache schedule journal_write work to
system_wq, that is a public workqueue in system, without WQ_MEM_RECLAIM
flag. system_wq is also a bound wq, and there
Hi Stefan,
This bug was triggered by following condition:
1, few system memory available to allocate
2, journal delayed its operations to system_wq, which needs to allocate
memory to execute.
3, Due to lack of memory, kernel starts to reclaim system memory, and
trigger writeback to file
Hi Stefan,
This bug was triggered by following condition:
1, few system memory available to allocate
2, journal delayed its operations to system_wq, which needs to allocate
memory to execute.
3, Due to lack of memory, kernel starts to reclaim system memory, and
trigger writeback to file
On Thu, Sep 27, 2018 at 11:17:47PM +0200, Borislav Petkov wrote:
> On Thu, Sep 27, 2018 at 04:31:46PM -0400, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma
> >
> > This kernel parameter allows to change the padding used
> > for the physical memory mapping section when KASLR
> > memory is
On Thu, Sep 27, 2018 at 11:17:47PM +0200, Borislav Petkov wrote:
> On Thu, Sep 27, 2018 at 04:31:46PM -0400, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma
> >
> > This kernel parameter allows to change the padding used
> > for the physical memory mapping section when KASLR
> > memory is
Hi Rasmus,
2018年9月27日(木) 3:58 Rasmus Villemoes :
>
> On 15 August 2018 at 16:27, Rasmus Villemoes wrote:
> > These patches eliminate two (albeit tiny and shortlived) processes
> > from the cmd_and_fixdep rule, i.e. from every TU being
> > compiled. Whether the diffstat below is worth it I'll
Hi Rasmus,
2018年9月27日(木) 3:58 Rasmus Villemoes :
>
> On 15 August 2018 at 16:27, Rasmus Villemoes wrote:
> > These patches eliminate two (albeit tiny and shortlived) processes
> > from the cmd_and_fixdep rule, i.e. from every TU being
> > compiled. Whether the diffstat below is worth it I'll
On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
>> Similar to fd_install/__fd_install, we want to be able to replace an fd of
>> an arbitrary struct files_struct, not just current's. We'll use this in the
>> next patch to implement the
On Thu, Sep 27, 2018 at 11:14:25PM +0200, Borislav Petkov wrote:
> On Thu, Sep 27, 2018 at 04:31:45PM -0400, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma
> >
> > Add warning message if the padding size for KASLR,
> > rand_mem_physical_padding, is not enough. The message also
> > says the
On Thu, Sep 27, 2018 at 2:59 PM, Kees Cook wrote:
> On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
>> Similar to fd_install/__fd_install, we want to be able to replace an fd of
>> an arbitrary struct files_struct, not just current's. We'll use this in the
>> next patch to implement the
On Thu, Sep 27, 2018 at 11:14:25PM +0200, Borislav Petkov wrote:
> On Thu, Sep 27, 2018 at 04:31:45PM -0400, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma
> >
> > Add warning message if the padding size for KASLR,
> > rand_mem_physical_padding, is not enough. The message also
> > says the
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c: In function
'halbtc_leave_lps':
drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c:284:21: warning:
variable 'ppsc' set but not used [-Wunused-but-set-variable]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c: In function
'halbtc_leave_lps':
drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c:284:21: warning:
variable 'ppsc' set but not used [-Wunused-but-set-variable]
Creates new Makefile to avoid building driver if
'make drivers/oprofile/' is called directly.
This driver is usually built from arch/$ARCH and seems to have
no meaning building alone.
Signed-off-by: Leonardo Brás
---
drivers/oprofile/Makefile | 1 +
1 file changed, 1 insertion(+)
create mode
Adds Makefile to enable building the driver using
'make drivers/hwtracing/'.
Changes drivers/Makefile to call the new Makefile directly.
It enables user building this driver without building the whole drivers/
subtree.
Signed-off-by: Leonardo Brás
---
drivers/Makefile | 4 +---
Creates new Makefile to avoid building driver if
'make drivers/oprofile/' is called directly.
This driver is usually built from arch/$ARCH and seems to have
no meaning building alone.
Signed-off-by: Leonardo Brás
---
drivers/oprofile/Makefile | 1 +
1 file changed, 1 insertion(+)
create mode
Adds Makefile to enable building the driver using
'make drivers/hwtracing/'.
Changes drivers/Makefile to call the new Makefile directly.
It enables user building this driver without building the whole drivers/
subtree.
Signed-off-by: Leonardo Brás
---
drivers/Makefile | 4 +---
Avoids building s390 drivers if 'make drivers/s390/' is called but
ARCH is not s390.
Signed-off-by: Leonardo Brás
---
drivers/s390/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/Makefile b/drivers/s390/Makefile
index a863b0462b43..0575f02dba45
Avoids building s390 drivers if 'make drivers/s390/' is called but
ARCH is not s390.
Signed-off-by: Leonardo Brás
---
drivers/s390/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/Makefile b/drivers/s390/Makefile
index a863b0462b43..0575f02dba45
Avoids building proc.o if 'make drivers/zorro/' is called and
CONFIG_ZORRO is disabled, even if CONFIG_PROC_FS is enabled.
Signed-off-by: Leonardo Brás
---
drivers/zorro/Makefile | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/zorro/Makefile
Avoids building proc.o if 'make drivers/zorro/' is called and
CONFIG_ZORRO is disabled, even if CONFIG_PROC_FS is enabled.
Signed-off-by: Leonardo Brás
---
drivers/zorro/Makefile | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/zorro/Makefile
Avoids building driver if 'make drivers/parisc/' is called and
CONFIG_PARISC is disabled.
Signed-off-by: Leonardo Brás
---
drivers/parisc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/parisc/Makefile b/drivers/parisc/Makefile
index
Special thanks for the feedback from:
- Finn Thain (I fixed the build problem)
- Geert Uytterhoeven (The cross compilers were very useful)
- Rolf Eike Beer (Was unintentional, thanks for the help!)
This Patchset changes some driver's Makefile to allow them building
using the command 'make
Avoids building driver if 'make drivers/nubus/' is called and
CONFIG_NUBUS is disabled.
Avoids building proc.o if CONFIG_PROC_FS is enabled but
CONFIG_NUBUS is disabled.
Signed-off-by: Leonardo Brás
---
drivers/nubus/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
Avoids building driver if 'make drivers/parisc/' is called and
CONFIG_PARISC is disabled.
Signed-off-by: Leonardo Brás
---
drivers/parisc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/parisc/Makefile b/drivers/parisc/Makefile
index
Special thanks for the feedback from:
- Finn Thain (I fixed the build problem)
- Geert Uytterhoeven (The cross compilers were very useful)
- Rolf Eike Beer (Was unintentional, thanks for the help!)
This Patchset changes some driver's Makefile to allow them building
using the command 'make
Avoids building driver if 'make drivers/nubus/' is called and
CONFIG_NUBUS is disabled.
Avoids building proc.o if CONFIG_PROC_FS is enabled but
CONFIG_NUBUS is disabled.
Signed-off-by: Leonardo Brás
---
drivers/nubus/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
1 - 100 of 2512 matches
Mail list logo
