From: Jakub Sitnicki
Date: Mon, 24 Oct 2016 11:28:51 +0200
> diff --git a/include/linux/icmpv6.h b/include/linux/icmpv6.h
> index 57086e9..6282e03 100644
> --- a/include/linux/icmpv6.h
> +++ b/include/linux/icmpv6.h
> @@ -45,4 +45,6 @@ extern void icmpv6_flow_init(struct
On Wed, Oct 26, 2016 at 01:19:02PM +0200, Lukas Wunner wrote:
> Hi Rafael,
>
> sorry for not responding to v5 of your series earlier, just sending
> this out now in the hope that it reaches you before your travels.
>
> On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote:
> > - Modif
On Thu, Oct 27, 2016 at 07:42:27AM +0200, Hannes Reinecke wrote:
> On 10/26/2016 09:43 PM, Bjorn Helgaas wrote:
> > Hi Johannes,
> >
> > On Wed, Oct 26, 2016 at 03:53:34PM +0200, Johannes Thumshirn wrote:
> >> The Read Completion Boundary bit must only be set on a device or endpoint
> >> if
> >>
From: Jakub Sitnicki
Date: Mon, 24 Oct 2016 11:28:52 +0200
> + inner_iph = skb_header_pointer(
> + skb, skb_transport_offset(skb) + sizeof(*icmph),
> + sizeof(_inner_iph), &_inner_iph);
Please do not style this call like this, put as many arguments as
you can on the f
On Thu, 2016-10-27 at 15:26 +, Vadim Pasternak wrote:
> > -Original Message-
> > From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> > Sent: Thursday, October 27, 2016 4:59 PM
> > To: Vadim Pasternak ; dvh...@infradead.org;
> > fengguang...@intel.com
> > Cc: da...@davemlo
Some macro for DA8xx CFGCHIP are defined in usb-davinci.h,
but da8xx-cfgchip.h intend to replace them.
Remove duplicated defines between da8xx-cfgchip.h and usb-davinci.h
Signed-off-by: Alexandre Bailon
---
arch/arm/mach-davinci/board-da830-evm.c | 5 +++--
arch/arm/mach-davinci/board-omapl
This patch is to address a proposal by Andy in this thread:
http://www.spinics.net/lists/dmaengine/msg11506.html
Split platform data to actual hardware properties, and platform quirks.
Now we able to use quirks and hardware properties separately from
different sources (pdata, device tree or autocon
+Marek,
Hello,
On 10/20/2016 08:27 AM, Sylwester Nawrocki wrote:
> On 10/20/2016 12:41 PM, Javier Martinez Canillas wrote:
>> I see no relevant changes in exynos_defconfig between v4.7..v4.8 and
>> also no changes in drivers/Makefile that could cause things to be
>> initialized on a different ord
On Mon, Oct 10, 2016 at 02:36:31PM +0200, Rafael J. Wysocki wrote:
> Hi Everyone,
>
> > On Thursday, September 08, 2016 11:25:44 PM Rafael J. Wysocki wrote:
> >
>
> [cut]
>
> >
> > Time for another update. :-)
> >
> > Fewer changes this time, mostly to address issues found by Lukas and Marek.
This patch implements compaction worker thread for z3fold. This
worker does not free up any pages directly but it allows for a
denser placement of compressed objects which results in less
actual pages consumed and higher compression ratio therefore.
This patch has been checked with the latest Linu
On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote:
> +/*
> + * Device link flags.
> + *
> + * STATELESS: The core won't track the presence of supplier/consumer drivers.
> + * AUTOREMOVE: Remove this link automatically on consumer driver unbind.
> + */
> +#define DL_FLAG_STATELESS
Add ECC error codes to enable the appropriate handling in the target.
Signed-off-by: Javier González
---
include/linux/lightnvm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
index e3ccaff..33643ae 100644
--- a/include/linux/lightnvm.h
rrpc cannot handle bios of size > 256kb due to NVME's 64 bit completion
bitmap. If a larger bio comes, split it explicitly.
Signed-off-by: Javier González
---
drivers/lightnvm/rrpc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index
Bad blocks should be managed by block owners. This would be either
targets for data blocks or sysblk for system blocks.
In order to support this, export two functions: One to mark a block as
an specific type (e.g., bad block) and another to update the bad block
table on the device.
Move bad block
On 2016-10-27 16:53:48 [+0200], Petr Mladek wrote:
>
> In each case, I wonder if the problem is caused by the conversion
> to the kthread worker or by the CPU hotplug state conversion.
drop the hotplug patch and you will see.
> Best Regards,
> Petr
Sebastian
On Mon, Oct 24, 2016 at 11:59:20AM +0800, Kefeng Wang wrote:
> Hi Greg, any more comments, thanks.
Never wait, just resend if you have comments and you know you have to
fix them up...
On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni
wrote:
> On Thu, 27 Oct 2016 09:07:55 +, Alexey Brodkin wrote:
>
>> > axs101 is using a 770 core, while the toolchain is built for the HS38
>> > core. I'm somewhat surprised that a single ARC toolchain cannot produce
>> > code for both 770 and
On Thursday, October 27, 2016 10:13:27 AM CEST Jarod Wilson wrote:
> On Thu, Oct 27, 2016 at 03:57:41PM +0200, Arnd Bergmann wrote:
> > With gcc-5 or higher on x86, we can get a bogus warning in the
> > dvb-net code:
> >
> > drivers/media/dvb-core/dvb_net.c: In function ‘dvb_net_ule’:
> > arch/x86
On 27/10/2016 11:32, Lorenzo Stoakes wrote:
> On Thu, Oct 27, 2016 at 11:27:24AM +0200, Paolo Bonzini wrote:
>>
>>
>> On 27/10/2016 02:12, Andrew Morton wrote:
>>>
>>>
Subject: [PATCH v2] mm: remove unnecessary __get_user_pages_unlocked()
calls
>>>
>>> The patch is rather misidentified
From: Jakub Sitnicki
Date: Mon, 24 Oct 2016 11:28:47 +0200
> However, for it to work IPv6 flow labels have to be same in both
> directions (i.e. reflected) or need to be chosen in a manner that
> ensures that the flow going in the opposite direction would actually
> be routed to a given path.
My
On Thu, Oct 27, 2016 at 10:07:42AM +0100, Mel Gorman wrote:
> > Something like so could work I suppose, but then there's a slight
> > regression in the page_unlock() path, where we now do an unconditional
> > spinlock; iow. we loose the unlocked waitqueue_active() test.
> >
>
> I can't convince m
Hi,
On 27-10-16 15:41, Rob Herring wrote:
Please Cc the maintainers of drivers/of/.
+ Frank R, Hans, Dmitry S
On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart
wrote:
Hi all,
Many boards now come with dips and compatible capes; among others the
C.H.I.P, or Beaglebones. All these boards have a
On Thu 27-10-16 12:55:27, Michal Hocko wrote:
> On Thu 27-10-16 10:51:40, Lorenzo Stoakes wrote:
> > This patch adds a int *locked parameter to get_user_pages_remote() to allow
> > VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked().
> >
> > Taking into account the previous ad
Arnd Bergmann wrote:
> A bugfix added a sanity check around the assignment and use of the
> 'is_11d' variable, which looks correct to me, but as the function is
> rather complex already, this confuses the compiler to the point where
> it can no longer figure out if the variable is always initializ
With gcc-5 or higher on x86, we can get a bogus warning in the
dvb-net code:
drivers/media/dvb-core/dvb_net.c: In function ‘dvb_net_ule’:
arch/x86/include/asm/string_32.h:77:14: error: ‘dest_addr’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
drivers/media/dvb-core/dvb_
On Friday, October 21, 2016 9:45:36 AM CEST Ruqiang Ju wrote:
> Add PCIe controller drvier for HiSilicon STB SoCs,
> the controller is based on the DesignWare's PCIe core.
>
> Signed-off-by: Ruqiang Ju
> ---
> .../bindings/pci/hisilicon-histb-pcie.txt | 66 +++
> drivers/pci/host/Kconf
On Wed, Oct 26, 2016 at 10:54:16PM +0200, Pavel Machek wrote:
> Hi!
>
> I'd like to get an interrupt every million cache misses... to do a
> printk() or something like that. As far as I can tell, modern hardware
> should allow me to do that. AFAICT performance events subsystem can do
> something l
On Wed, Oct 19, 2016 at 05:46:11PM -0700, Brian Norris wrote:
> Ugh, as I hope the patch context makes clear, the subject should be
>
> s/early/late/
>
> as should the body of the commit message.
>
> On Wed, Oct 19, 2016 at 05:26:10PM -0700, Brian Norris wrote:
> > Consider two devices, A and B,
On 27/10/2016 02:12, Andrew Morton wrote:
>
>
>> Subject: [PATCH v2] mm: remove unnecessary __get_user_pages_unlocked() calls
>
> The patch is rather misidentified.
>
>> virt/kvm/async_pf.c | 7 ---
>> virt/kvm/kvm_main.c | 5 ++---
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>
On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
> We recently encountered a bug where a few customers using ibmveth on the
> same LPAR hit an issue where a TCP session hung when large receive was
> enabled. Closer analysis revealed that the session was stuck because the
> one side was adver
On 10/27/2016 5:41 PM, Jike Song wrote:
> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
>> Update arguments of vaddr_get_pfn() to take struct mm_struct *mm as input
>> argument.
>>
>> Signed-off-by: Kirti Wankhede
>> Signed-off-by: Neo Jia
>> Change-Id: I885fd4cd4a9f66f4ee2c1caf58267464ec239f52
Nikolay Borisov writes:
> On 10/11/2016 10:36 AM, Nikolay Borisov wrote:
>> This patchset converts inotify to using the newly introduced
>> per-userns sysctl infrastructure.
>>
>> Currently the inotify instances/watches are being accounted in the
>> user_struct structure. This means that in setu
On 10/27/2016 05:38 PM, Javier Martinez Canillas wrote:
> +Marek,
>
> Hello,
>
> On 10/20/2016 08:27 AM, Sylwester Nawrocki wrote:
>> On 10/20/2016 12:41 PM, Javier Martinez Canillas wrote:
>>> I see no relevant changes in exynos_defconfig between v4.7..v4.8 and
>>> also no changes in drivers/Mak
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
Signed-off-by: Antoine Tenart
---
Please provide a commit message.
drivers/of/overlay-manager/Kconfig | 10 ++
drivers/w1/slaves/w1_ds2431.c | 39 ++
2 files changed, 49 insertions(+)
diff --gi
On 10/27/2016 06:29 AM, Sekhar Nori wrote:
On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
The LEDs default-on trigger is nice to have. For example, it can be used
to configure a LED as a power indicator.
Signed-off-by: David Lechner
---
arch/arm/configs/davinci_all_defconfig | 1 +
spin_lock_irqsave(&p->pi_lock, flags);
WARN_ON(1);
raw_spin_unlock_irqrestore(&p->pi_lock, flags);
e) printk from console_cont_flush() /*and down the call chain */
printk()
console_unlock()
call_console_drivers()
...
WARN_ON(1);
[[against next-20161027
Hello Sylwester,
On 10/27/2016 12:48 PM, Sylwester Nawrocki wrote:
> On 10/27/2016 05:38 PM, Javier Martinez Canillas wrote:
>> +Marek,
>>
>> Hello,
>>
>> On 10/20/2016 08:27 AM, Sylwester Nawrocki wrote:
>>> On 10/20/2016 12:41 PM, Javier Martinez Canillas wrote:
I see no relevant changes in
On Thu, Oct 27, 2016 at 05:01:51PM +0200, Greg KH wrote:
> On Thu, Oct 27, 2016 at 12:47:11PM +0200, Zahari Doychev wrote:
> > This patch series adds support for the Data Modul Embedded Controller(dmec)
> > which is implemented within an on board FPGA found on Data Modul embedded
> > CPU modules.
>
The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for
printing continuation lines") allows to define more message headers
for a single message. The motivation is that continuous lines might
get mixed. Therefore it make sense to define the right log level
for every piece of a cont li
The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for
printing continuation lines") allows to define more message headers
for a single message. The motivation is that continuous lines might
get mixed. Therefore it make sense to define the right log level
for every piece of a cont li
This patch extends the idea of NMI per-cpu buffers to regions
that may cause recursive printk() calls and possible deadlocks.
Namely, printk() can't handle printk calls from schedule code
or printk() calls from lock debugging code (spin_dump() for instance);
because those may be called with `sem->l
The commit 4bcc595ccd80decb4245 ("printk: reinstate KERN_CONT for printing
continuation lines") added back KERN_CONT message header. As a result
it might appear in the middle of the line when the parts are squashed
via the temporary NMI buffer.
A reasonable solution seems to be to split the text i
On 10/26/2016 05:26 AM, Sekhar Nori wrote:
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
Add a node for the new usb phy driver.
changed this to:
Add a node for usb phy device. This device
controls both the USB 1.1 and USB 2.0 PHYs.
mainly because the node is for the dev
On Thu, 2016-10-27 at 18:34 +0300, Eugeniy Paltsev wrote:
> This patch is to address a proposal by Andy in this thread:
> http://www.spinics.net/lists/dmaengine/msg11506.html
> Split platform data to actual hardware properties, and platform
> quirks.
> Now we able to use quirks and hardware propert
A preparation patch for printk_safe work. No functional change.
- rename nmi.c to print_safe.c
- rename exported functions to have `safe' prefix.
Signed-off-by: Sergey Senozhatsky
Acked-by: Steven Rostedt
---
arch/arm/kernel/smp.c | 4 +-
include/linux/hardirq.h
We use printk-safe now which makes printk-recursion detection code
in vprintk_emit() is unreachable. The tricky thing here is that,
apart from detecting and reporting printk recursions, that code also
used to zap_lockc() in case of panic. However, zap_locks() does not
look to be needed anymore:
1)
The first patch fixes a messed output of continuous lines
when printing backtraces for all CPUs via NMI. It works
well for me.
The other patches fix problems that I noticed when working
on the first patch. It would be great if the respective
maintainers could do some more testing of them.
Well, i
If CONFIG_NVM is disabled, loading null_block module with use_lightnvm=1
fails. But there are no messages and documents related to the failure.
So the patch adds the notes to use LightNVM.
Signed-off-by: Yasuaki Ishimatsu
Cc: Jens Axboe
---
Documentation/block/null_blk.txt | 2 +-
drivers/blo
The commit 4bcc595ccd80decb4245096e ("printk: reinstate KERN_CONT for
printing continuation lines") allows to define more message headers
for a single message. The motivation is that continuous lines might
get mixed. Therefore it make sense to define the right log level
for every piece of a cont li
Use printk_safe per-CPU buffers in in printk recursion-prone blocks:
-- around logbuf_lock protected sections in vprintk_emit() and
console_unlock()
-- around down_trylock_console_sem() and up_console_sem()
Note that this solution addresses deadlocks caused by printk()
recursive calls only.
Ex
Account lost messages in pritk-safe and printk-safe-nmi
contexts and report those numbers during printk_safe_flush().
Signed-off-by: Sergey Senozhatsky
---
kernel/printk/internal.h| 17 ---
kernel/printk/printk.c | 10 -
kernel/printk/printk_safe.c | 50 +
On Fri, Oct 21, 2016 at 4:57 PM, wrote:
>> -Original Message-
>> From: Amir Levy [mailto:amir.jer.l...@intel.com]
>> Sent: Wednesday, September 28, 2016 9:44 AM
>> To: gre...@linuxfoundation.org
>> Cc: andreas.noe...@gmail.com; bhelg...@google.com; cor...@lwn.net;
>> linux-kernel@vger.ker
vprintk(), just like printk(), better be using per-cpu printk_func
instead of direct vprintk_emit() call. Just in case if vprintk()
will ever be called from NMI, or from any other context that can
deadlock in printk().
Signed-off-by: Sergey Senozhatsky
Reviewed-by: Steven Rostedt
---
kernel/pri
Tero Kristo writes:
> On 19/10/16 02:08, Nishanth Menon wrote:
>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>> changes.
>
> Any final comments on this series, or shall I send a pull-req forward?
> Very minimal changes compared to v3 so should be good to go imo.
Not
On 27.10.2016, Grozdan wrote:
> So in the end, I'm here to support the inclusion of BFQ. Paolo has put
> too much energy, time, and sleepless nights into this so people like
> me can have a working, responsive system during heavy disk operations.
> From a normal user's perspective, I do not want
On 10/27/2016 8:00 PM, Alex Williamson wrote:
> On Thu, 27 Oct 2016 18:01:51 +0530
> Kirti Wankhede wrote:
>
>> On 10/27/2016 12:50 PM, Alexey Kardashevskiy wrote:
>>> On 18/10/16 08:22, Kirti Wankhede wrote:
VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
M
Hi Robert,
On Mon, Oct 17, 2016 at 08:58:01PM +0200, Robert Richter wrote:
> Mark, Will, any opinion here?
Having looking at this, I'm inclined to agree with you; pfn_valid() is
all about whether the underlying mem_map (struct page *) entry exists,
not about whether the page is mappable or not.
> On Oct 21, 2016, at 3:08 AM, Michal Hocko wrote:
>
> Interesting.
> $ cat /debug/tracing/available_tracers
> function_graph preemptirqsoff preemptoff irqsoff function nop
>
> Do I have to configure anything specially? And if I do why isn't it any
> better to simply add a start tracepoint and
On 10/27/16 05:18, Rob Herring wrote:
> On Tue, Oct 25, 2016 at 3:58 PM, wrote:
>> From: Frank Rowand
>>
>> Remove comments that state the obvious, to reduce clutter
>
> I'm probably not the best reviewer, have you ever seen a comment in my code.
> :)
>
>>
>> Signed-off-by: Frank Rowand
>> -
During exec dumpable is cleared if the file that is being executed is
not readable by the user executing the file. A bug in
ptrace_may_access allows reading the file if the executable happens to
enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
unshare(CLONE_NEWUSER), or setns(fd
A recent rework accidentally left a debugging printk untouched
while changing the meaning of the variables, leading to an
uninitialized variable being printed:
drivers/media/i2c/ir-kbd-i2c.c: In function 'get_key_haup_common':
drivers/media/i2c/ir-kbd-i2c.c:62:2: error: 'toggle' may be used uninit
On Thu, Oct 27, 2016 at 05:34:06PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 19, 2016 at 05:46:11PM -0700, Brian Norris wrote:
> > Ugh, as I hope the patch context makes clear, the subject should be
> >
> > s/early/late/
> >
> > as should the body of the commit message.
[...]
> > If the patc
On 10/27/16 05:21, Rob Herring wrote:
> On Tue, Oct 25, 2016 at 3:58 PM, wrote:
>> From: Frank Rowand
>
> Maybe some should be debug?
>
>> Signed-off-by: Frank Rowand
>> ---
>> drivers/of/resolver.c | 28
>> 1 file changed, 28 deletions(-)
>>
>> diff --git a/driv
Le 27/10/2016 à 18:04, Richard Genoud a écrit :
> After commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
> when hardware handshake is enabled"), the hardware handshake wasn't
> functional anymore on Atmel platforms (beside SAMA5D2).
>
> To understand why, one has to understand the f
On Tue, Oct 25, 2016 at 12:22:47AM +0200, Arnd Bergmann wrote:
> On Monday, October 24, 2016 12:30:47 PM CEST Chris Metcalf wrote:
> > On 10/21/2016 4:33 PM, Yury Norov wrote:
> > > All new 32-bit architectures should have 64-bit off_t type, but existing
> > > architectures has 32-bit ones.
> > >
>
After commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
when hardware handshake is enabled"), the hardware handshake wasn't
functional anymore on Atmel platforms (beside SAMA5D2).
To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS
first:
Before commit 1cf6e8fc8341
Consider two devices, A and B, where B is a child of A, and B utilizes
asynchronous suspend (it does not matter whether A is sync or async). If
B fails to suspend_noirq() or suspend_late(), or is interrupted by a
wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
variable. Howeve
On 10/27/16 06:51, Pantelis Antoniou wrote:
> Hi Rob, Frank,
>
>> On Oct 27, 2016, at 15:21 , Rob Herring wrote:
>>
>> On Tue, Oct 25, 2016 at 3:58 PM, wrote:
>>> From: Frank Rowand
>>
>> Maybe some should be debug?
>>
>
> Yes, please do not get rid of them completely.
> Leave them at least a
On Thu, 2016-10-27 at 17:52 +0200, Petr Mladek wrote:
> Note that 3 bytes should be enough for the header buffer. I am not
> sure where the 4 bytes came from. Maybe it expected that both
> KERN_SOH and the log level strings end with '\0' but they
> are concatenated.
I believe it was from when KERN
On Wed, 26 Oct 2016 21:59:52 -0200
Sergio Prado wrote:
> This series adds support for configuring Samsung's s3c2410 and
> compatible flash memory controller via devicetree.
>
> Tested on FriendlyARM mini2440, based on s3c2440 SoC.
>
> Patch 3 depends on patch 1.
Applied.
Thanks,
Boris
>
>
While merging mpt3sas & mpt2sas code, we posted below patch for WarpDrive
support,
mpt3sas: Ported WarpDrive product SSS6200 support
commit id is 7786ab6aff
In this patch and in the below hunk, we have added is_warpdrive
check condition on the wrong line
--
On 10/27/2016 11:00 AM, Andrew Cooper wrote:
On 27/10/16 15:25, Boris Ostrovsky wrote:
On 10/14/2016 03:01 PM, Boris Ostrovsky wrote:
On 10/14/2016 02:41 PM, Andrew Cooper wrote:
On 14/10/16 19:05, Boris Ostrovsky wrote:
PVH guests don't receive ACPI hotplug interrupts and therefore
need
The page table dumping code always assumes it will be dumping to a
seq_file to userspace. Future code will be taking advantage of
the page table dumping code but will not need the seq_file. Make
the seq_file optional for these cases.
Reviewed-by: Kees Cook
Reviewed-by: Mark Rutland
Tested-by: M
This series is a followup to the single patch 'modversions: treat symbol
CRCs as 32 bit quantities on 64 bit archs', of which two versions have
been sent out so far [0][1]
As pointed out by Michael, GNU ld behaves a bit differently between arm64
and PowerPC64, and where the former gets rid of all
Page mappings with full RWX permissions are a security risk. x86
has an option to walk the page tables and dump any bad pages.
(See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar
implementation for arm64.
Reviewed-by: Kees Cook
Reviewed-by: Mark Rutland
Tested-by: Mark Rutland
S
On 10/27/2016 08:34 AM, Grozdan wrote:
On Thu, Oct 27, 2016 at 11:26 AM, Jan Kara wrote:
On Wed 26-10-16 10:12:38, Jens Axboe wrote:
On 10/26/2016 10:04 AM, Paolo Valente wrote:
Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha scritto:
On 10/26/2016 09:29 AM, Christoph Hellwig wrote:
The modversion symbol CRCs are emitted as ELF symbols, which allows us to
easily populate the kcrctab sections by relying on the linker to associate
each kcrctab slot with the correct value.
This has a couple of downsides:
- Given that the CRCs are treated as memory addresses, we waste 4 bytes
f
On Thu, Oct 27, 2016 at 1:45 AM, Marc Kleine-Budde wrote:
> On 10/24/2016 10:17 PM, Cong Wang wrote:
>> On Mon, Oct 24, 2016 at 1:10 PM, Cong Wang wrote:
>>> On Mon, Oct 24, 2016 at 12:11 PM, Oliver Hartkopp
>>> wrote:
if (proc_dir) {
/* unique socket address as
Hi,
This is v4 of the implementation to check for writable and executable pages on
arm64. This version contains a review from Ard and makes the UXN page count
a separate variable. Overall, minor changes.
Thanks,
Laura
Laura Abbott (4):
arm64: dump: Make ptdump debugfs a separate option
arm64
max_addr was added as part of struct ptdump_info but has never actually
been used. Remove it.
Reviewed-by: Kees Cook
Reviewed-by: Mark Rutland
Tested-by: Mark Rutland
Signed-off-by: Laura Abbott
---
v4: No changes
---
arch/arm64/include/asm/ptdump.h | 1 -
1 file changed, 1 deletion(-)
diff
In preparation of modifying the core modversions code to emit the CRCs
as 32-bit quantities, ensure that 64-bit PowerPC will be able to deal
with this when CONFIG_RELOCATABLE=y, in which case the CRCs will be
emitted into the final ELF binary as R_PPC64_ADDR32 relocations.
Since 32-bit relocations
On 10/27/16 07:41, Pantelis Antoniou wrote:
> Hi Frank,
>
>
>> On Oct 25, 2016, at 23:59 , frowand.l...@gmail.com wrote:
>>
>> From: Frank Rowand
>>
>> This unused variable is a reminder that symbols in overlays are
>> not available to subsequent overlays. If such a feature is
>> desired then t
Commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix causes
perf issues") fixed an issue with relocatable PIE kernels in a way that
essentially reintroduced the issue again for 32-bit builds.
Since the chosen approach does is not applicable to 32-bit, fix the
issue by updating the runt
The MPOL_F_STATIC_NODES and MPOL_F_RELATIVE_NODES flags are irrelevant
when setting them for MPOL_LOCAL NUMA memory policy via set_mempolicy
or mbind.
Return the "invalid argument" from set_mempolicy and mbind whenever
any of these flags is passed along with MPOL_LOCAL.
It is consistent with MPOL_P
ptdump_register currently initializes a set of page table information and
registers debugfs. There are uses for the ptdump option without wanting the
debugfs options. Split this out to make it a separate option.
Reviewed-by: Ard Biesheuvel
Reviewed-by: Kees Cook
Reviewed-by: Mark Rutland
Teste
On 10/27/2016 03:26 AM, Jan Kara wrote:
On Wed 26-10-16 10:12:38, Jens Axboe wrote:
On 10/26/2016 10:04 AM, Paolo Valente wrote:
Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha scritto:
On 10/26/2016 09:29 AM, Christoph Hellwig wrote:
On Wed, Oct 26, 2016 at 05:13:07PM +0200, Arnd Ber
This series is a followup to the single patch 'modversions: treat symbol
CRCs as 32 bit quantities on 64 bit archs', of which two versions have
been sent out so far [0][1]
As pointed out by Michael, GNU ld behaves a bit differently between arm64
and PowerPC64, and where the former gets rid of all
On Wed, Oct 26, 2016 at 11:33 PM, Christoph Hellwig wrote:
>> Dave, can you hit the warnings with this? Totally untested...
>
> Can we just kill off the unhelpful blk_map_ctx structure, e.g.:
Yeah, I found that hard to read too. The difference between
blk_map_ctx and blk_mq_alloc_data is minimal,
2016-10-26 20:17-0400, Bandan Das:
> Radim Krčmář writes:
> ...
>> +static int check_fxsr(struct x86_emulate_ctxt *ctxt)
>> +{
>> +u32 eax = 1, ebx, ecx = 0, edx;
>> +
>> +ctxt->ops->get_cpuid(ctxt, &eax, &ebx, &ecx, &edx);
>> +if (!(edx & FFL(FXSR)))
>> +return emulate_ud(
On Thu, 2016-10-27 at 17:52 +0200, Petr Mladek wrote:
> The commit 4bcc595ccd80decb4245 ("printk: reinstate KERN_CONT for printing
> continuation lines") added back KERN_CONT message header. As a result
> it might appear in the middle of the line when the parts are squashed
> via the temporary NMI
On 10/27/16 05:47, Rob Herring wrote:
> On Tue, Oct 25, 2016 at 3:58 PM, wrote:
>> From: Frank Rowand
>
> I prefer to leave the prefixes and this is getting into pointless churn.
>
>>
>> Signed-off-by: Frank Rowand
>> ---
>> drivers/of/resolver.c | 10 +-
>> 1 file changed, 5 inserti
On 10/27/2016 10:34 AM, Linus Torvalds wrote:
On Wed, Oct 26, 2016 at 11:33 PM, Christoph Hellwig wrote:
Dave, can you hit the warnings with this? Totally untested...
Can we just kill off the unhelpful blk_map_ctx structure, e.g.:
Yeah, I found that hard to read too. The difference between
On 10/27/16 05:03, Rob Herring wrote:
> On Tue, Oct 25, 2016 at 4:02 PM, Frank Rowand wrote:
>> On 10/25/16 13:58, frowand.l...@gmail.com wrote:
>>> From: Frank Rowand
>>>
>>> drivers/of/resolve.c is a bit difficult to read. Clean it up so
>>> that review of future overlay related patches will b
Add a set_ldisc function to enable/disable IrDA SIR mode according to
the new line discipline.
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_dw.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw
Expose set_ldisc() function so that it can be overridden with a
platform specific implementation.
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_core.c | 3 +++
drivers/tty/serial/8250/8250_port.c | 12 ++--
include/linux/serial_8250.h | 4
include/linux/serial_c
On Thu, Oct 27, 2016 at 8:25 AM, Tom Gundersen wrote:
>
> Could you elaborate on why you think syscalls would be more
> appropriate than ioctls?
ioctl's tend to be a horrid mess both for things like compat.but also
for things like system call tracing and filtering (ie BPF).
The compat mess is fi
Hi Linus,
A set of fixes for this series, most notably the fix for the blk-mq
software queue regression in from this merge window.
Apart from that, a fix for an unlikely hang if a queue is flooded with
FUA requests from Ming, and a few small fixes for nbd and badblocks.
Lastly, a rename update f
On Thu, Oct 27, 2016 at 6:37 PM, Linus Torvalds
wrote:
> On Thu, Oct 27, 2016 at 8:25 AM, Tom Gundersen wrote:
>>
>> Could you elaborate on why you think syscalls would be more
>> appropriate than ioctls?
>
> ioctl's tend to be a horrid mess both for things like compat.but also
> for things like
From: Phil Elwell
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Spurious interrupts are still possible for other
From: Phil Elwell
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.
Spurious interrupts are still possible for other
301 - 400 of 847 matches
Mail list logo
