On Tue, Apr 3, 2018 at 3:13 PM, Andreas Radke wrote:
> Am Mon, 2 Apr 2018 08:34:35 -0400
> schrieb Jason Andryuk :
>
>> The HP EliteBook G3 850 has a weird bug where a subsequent cold boot
>> hangs while plugged in if Linux enables the Host Notify features of
>> i2c-i801. The cold boot hang depe
Hi,
On 04/04/18 13:36, Jan Kara wrote:
Hi,
On Wed 04-04-18 10:24:48, Steven Whitehouse wrote:
On 03/04/18 13:05, Jan Kara wrote:
Hello,
On Sun 01-04-18 10:01:02, syzbot wrote:
syzbot hit the following crash on upstream commit
10b84daddbec72c6b440216a69de9a9605127f7a (Sat Mar 31 17:59:00 20
On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> What I'm afraid of is this turning into a "security" feature that ends up
> being circumvented in most scenarios where it's currently deployed - eg,
> module signatures are mostly worthless in the non-lockdown case because you
> can
On Wed, 4 Apr 2018 08:20:39 +0200
Michal Hocko wrote:
> > Now can you please explain to me why si_mem_available is not suitable
> > for my purpose.
>
> Several problems. It is overly optimistic especially when we are close
> to OOM. The available pagecache or slab reclaimable objects might be
On Wed, 4 Apr 2018 21:33:38 +0900
Masami Hiramatsu wrote:
> Hmm, how can I undef ts0 and test it again?
> If I can not clean it, the testcase must fail on the 2nd time.
Tom,
I already pulled in your patches and almost completed my tests (which
obviously are not stress testing this code).
Any f
Hi Mylène,
On 03/04/18 07:18, Mylène Josserand wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value meaning that e
On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > What I'm afraid of is this turning into a "security" feature that ends up
> > being circumvented in most scenarios where it's currently deployed - eg,
> > module
Store preempting context switch out event into Perf trace as a part of
PERF_RECORD_SWITCH[_CPU_WIDE] record.
Percentage of preempting and non-preempting context switches help
understanding the nature of workloads (CPU or IO bound) that are running
on a machine;
The event is treated as preempt
://github.com/0day-ci/linux/commits/Xidong-Wang/drm-i915-Do-not-use-kfree-to-free-kmem_cache_alloc-return-value/20180404-193341
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a1-201813 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce
On Wed, Apr 04, 2018 at 06:56:32AM +0200, Ingo Molnar wrote:
>
> * Andrea Parri wrote:
>
> > In Ingo's words [1]:
> >
> > "[...] what should be done instead is to write a script that refreshes
> >all the arch-support.txt files in-place. [...]
> >
> >It's OK for the script to have va
Print additional 'preempt' tag for PERF_RECORD_SWITCH[_CPU_WIDE] OUT records
when
event header misc field contains PERF_RECORD_MISC_SWITCH_OUT_PREEMPT bit set
designating preemption context switch out event:
tools/perf/perf report -D -i perf.data | grep _SWITCH
0 768361415226 0x27f076 [0x28]:
Append 'p' sign to 'S' tag designating the type of context switch out event so
'Sp' means preemption context switch. Documentation is extended to cover
new presentation changes.
perf script --show-switch-events -F +misc -I -i perf.data:
hdparm 4073 [004] U 762.198265: 3801
Hello,
First of all, thank you for the patch. This generates more discussion than I
had anticipated, which is both good and bad. I'll comment through the e-mail,
and try to explain both my initial idea, and also where it could lead us.
On Tuesday, 27 March 2018 16:02:31 EEST jacopo mondi wrote:
On Wed 2018-03-14 14:44:36, Josh Poimboeuf wrote:
> On Wed, Mar 14, 2018 at 03:27:02PM -0400, Joe Lawrence wrote:
> > On Tue, Mar 13, 2018 at 04:54:47PM +0100, Petr Mladek wrote:
> > > The existing API allows to pass a sample data to initialize the shadow
> > > data. It works well when the data are
On Wed, Apr 4, 2018 at 2:53 PM, Arnd Bergmann wrote:
> A new set of warnings appeared in next-20180403 in some configurations
> when gcc cannot see that rbd_assert(0) leads to an unreachable code
> path:
>
> drivers/block/rbd.c: In function 'rbd_img_is_write':
> drivers/block/rbd.c:1397:1: error:
> What about the 'reset' functionality? Is there something in the power
> supply API for hooking in a GPIO based power switch (in my case it
> would be i2c) as I would think that would be common for ATX supplies?
> I didn't see anything in Documentation/power.
>
> This is what led me to the restar
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure a
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure a
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
This series converts all users of at24_pl
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure a
The information contained in the platform data struct is redundant.
Page size == 1 is the safe default assumed if no pagesize property is
given. The EEPROM size can be indicated to the driver using the
correct model name.
Drop the at24_platform_data entirely.
Signed-off-by: Bartosz Golaszewski
/commits/Ravi-Bangoria/trace_uprobe-Support-SDT-markers-having-reference-count-semaphore/20180404-201900
config: x86_64-randconfig-x019-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All
On 01/07/2018, 10:40 PM, Martin Kelly wrote:
> From: Martin Kelly
...
> --- a/tools/power/acpi/Makefile.config
> +++ b/tools/power/acpi/Makefile.config
> @@ -56,9 +56,6 @@ INSTALL_SCRIPT = ${INSTALL_PROGRAM}
> # to compile vs uClibc, that can be done here as well.
> CROSS = #/usr/i386-linux-ucli
On Wed, Apr 04, 2018 at 01:19:29PM +0200, Linus Walleij wrote:
>- There is a series of ISA_BUS_API changes that ended up
> getting queued in my tree. Most of them have proper ACKs
> and they have been tested throughly in linux-next.
> These patches finally split ISA_BUS and ISA_BUS_API
> apart
The commit 5149cbac4235: "locking/rwsem: Add DEBUG_RWSEMS to look for
lock/unlock emismatches" (newly added in this merge window) will cause
xfstests tests failures in generic/068 for all file systems.
This is because the freeze and thaw ioctls, by design, are run in
different processes. It looks
://github.com/0day-ci/linux/commits/Xidong-Wang/drm-i915-Do-not-use-kfree-to-free-kmem_cache_alloc-return-value/20180404-193341
base: git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
On Wed, Apr 4, 2018 at 8:16 AM, Daniel Vetter wrote:
> On Wed, Apr 04, 2018 at 07:40:32AM -0400, Rob Clark wrote:
>> On Wed, Apr 4, 2018 at 5:56 AM, Daniel Vetter wrote:
>> > On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
>> >> On 04/04/2018 10:43 AM, Daniel Vetter wrote:
>> >>
/commits/Ravi-Bangoria/trace_uprobe-Support-SDT-markers-having-reference-count-semaphore/20180404-201900
config: i386-randconfig-a0-201813 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors
On Wed, Apr 4, 2018 at 8:26 AM, Daniel Vetter wrote:
> On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark wrote:
>> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst
>> wrote:
>>> Op 04-04-18 om 13:37 schreef Rob Clark:
On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
wrote:
> Op 04-04-18
On Wed, Apr 4, 2018 at 3:24 PM, Rob Clark wrote:
> On Wed, Apr 4, 2018 at 8:16 AM, Daniel Vetter wrote:
>> On Wed, Apr 04, 2018 at 07:40:32AM -0400, Rob Clark wrote:
>>> On Wed, Apr 4, 2018 at 5:56 AM, Daniel Vetter wrote:
>>> > On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote:
>
On Wed, Apr 04, 2018 at 10:38:41AM +0200, Arnd Bergmann wrote:
> Also, now that the other architectures are gone, a lot of changes can
> be done more easily that will be incompatible with a pure revert, so
> the more time passes, the harder it will get to do that.
Yes, and an out-of-tree arch port
2018-04-04 19:54 GMT+08:00 David Hildenbrand :
> On 04.04.2018 01:28, Wanpeng Li wrote:
>> From: Wanpeng Li
>>
>> Introduce handle_ud() to handle invalid opcode, this function will be
>> used by later patches.
>>
>> Reviewed-by: Konrad Rzeszutek Wilk
>> Reviewed-by: Liran Alon
>> Cc: Paolo Bonzi
On Wed, 2018-04-04 at 08:57 -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > What I'm afraid of is this turning into a "security" feature that ends up
> > being circumvented in most scenarios where it's currently deployed - eg,
> > module signatu
The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb:
Linux 4.16-rc3 (2018-02-25 18:50:41 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git
tags/random_for_linus
for you to fetch changes up to 5e747dd9be54be
For making things build again:
Acked-by: Mike Looijmans
I'd be interested in use-cases for having nvmem as a module, I cannot think of
any.
I am working on splitting of_get_nvmem_mac_address(), by moving most of its
burden to the nvmem interface. Intend to create this "just give me my bytes
Theodore Y. Ts'o wrote:
> Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?
Lockdown mode restricts kexec to booting an authorised image (where t
Could this patch be picked up, please?
Thanks,
Tomeu
On 26 March 2018 at 13:51, Heiko Stübner wrote:
> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>> there, so if that's the case we have to make sure not to
On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > > What I'm afraid of is this turning into a "security" feature that ends up
> > > being ci
2018-04-04 19:59 GMT+08:00 David Hildenbrand :
>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 1eb495e..a55ecef 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -146,6 +146,9 @@ bool __read_mostly enable_vmware_backdoor = false;
>> module_param(enable_vmware_
On Wed, 4 Apr 2018 09:49:27 +0200
Peter Zijlstra wrote:
> On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote:
> > If you are concerned about attack surface, I could make it a bit more
> > difficult to tweak by malicious software. What about the patch below?
> > It would be much more d
On Wed, Apr 4, 2018 at 3:32 PM, Mike Looijmans wrote:
>
> Which may still be very confusing, since it means that CONFIG_MACB=y with
> CONFIG_NVMEM=m will fail, but setting both to "y" or both to "m" will work.
> So that would introduce more build failures again, right?
Right, it would require ha
Em Wed, Apr 04, 2018 at 09:05:16AM +0200, Jiri Olsa escreveu:
> On Tue, Apr 03, 2018 at 09:18:33PM +0300, Alexey Budankov wrote:
> >
> > Currently print count interval for performance counters values is
> > limited by 10ms so reading the values at frequencies higher than 100Hz
> > is restricted
On Wed, Apr 04 2018 at 5:54am -0400,
Arnd Bergmann wrote:
> Building device mapper with CONFIG_DAX=m now results in a link error:
>
> drivers/md/dm.o: In function `dm_put_table_device':
> dm.c:(.text+0x33c): undefined reference to `put_dax'
> drivers/md/dm.o: In function `cleanup_mapped_device'
On 4 April 2018 at 12:44, Valentin Schneider wrote:
> Hi,
>
> On 03/04/18 13:17, Vincent Guittot wrote:
>> Hi Valentin,
>>
> [...]
>>>
>>> I believe ASYM_PACKING behaves better here because the workload is only
>>> sysbench threads. As stated above, since task utilization is disregarded, I
>>
>> I
utente webmail
Tieni presente che il 95% delle tue e-mail ricevute dopo l'ultima volta che
hai bisogno di aggiornare il tuo server di versione webmail nel nostro database
sono state ritardate. Per ricevere e inviare i tuoi messaggi su base regolare.
Il nostro team tecnico di webmail aggiorner
[+cc linux-pci]
On Tue, Apr 03, 2018 at 04:15:05PM -0500, Gustavo A. R. Silva wrote:
> new_range is being dereferenced before it is null checked, hence
> there is a potential null pointer dereference.
>
> Fix this by moving the pointer dereference after new_range has
> been properly null checked.
-ci/linux/commits/Xidong-Wang/drm-i915-Do-not-use-kfree-to-free-kmem_cache_alloc-return-value/20180404-193341
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x009-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the
Hello Florian,
On Tue, 3 Apr 2018 12:56:30 -0700
Florian Fainelli wrote:
> On 04/02/2018 11:52 PM, Chen-Yu Tsai wrote:
> > On Tue, Apr 3, 2018 at 2:18 PM, Mylène Josserand
> > wrote:
> >> To add the support for SMP on sun8i-a83t, we will use some
> >> definitions in an assembly file so move d
On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen wrote:
> Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> casues the ring to get corrupted by allowing multiple kernel threads
> to claim ownership of the same ring entry, Mark the ring entry as
> already being used within the spin_lo
The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for you to fetch changes up to e40ff213898502d299
On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
> Theodore Y. Ts'o wrote:
>
> > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
> > isn't this a problem for people who are fearful that Linux could be
> > used as part of a Windows boot virus in a Secure UEFI contex
On 04/04/2018 09:23 AM, Theodore Y. Ts'o wrote:
> The commit 5149cbac4235: "locking/rwsem: Add DEBUG_RWSEMS to look for
> lock/unlock emismatches" (newly added in this merge window) will cause
> xfstests tests failures in generic/068 for all file systems.
>
> This is because the freeze and thaw ioc
On Wed, Apr 04, 2018 at 09:34:11AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote:
> > > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote:
> > > > What I'm afrai
Theodore Y. Ts'o wrote:
> > Lockdown mode restricts kexec to booting an authorised image (where the
> > authorisation may be by signature or by IMA).
>
> If that's true, then Matthew's assertion that lockdown w/o secure boot
> is insecure goes away, no?
No.
Lockdown prevents the running kernel
Hi Marc,
Thank you for the review.
On Wed, 4 Apr 2018 14:01:48 +0100
Marc Zyngier wrote:
> Hi Mylène,
>
> On 03/04/18 07:18, Mylène Josserand wrote:
> > The CNTVOFF register from arch timer is uninitialized.
> > It should be done by the bootloader but it is currently not the case,
> > even for
On Wed, Apr 4, 2018 at 2:54 AM, Arnd Bergmann wrote:
> Building device mapper with CONFIG_DAX=m now results in a link error:
>
> drivers/md/dm.o: In function `dm_put_table_device':
> dm.c:(.text+0x33c): undefined reference to `put_dax'
> drivers/md/dm.o: In function `cleanup_mapped_device':
> dm.c
Hi Jason, Andreas,
On Wed, 4 Apr 2018 08:55:20 -0400, Jason Andryuk wrote:
> On Tue, Apr 3, 2018 at 3:13 PM, Andreas Radke wrote:
> > I'm faced with similar cold boot issues on my HP ProBook 430 G4 model.
> > Trying your hint with adding
> > "options i2c_i801 disable_features=0x20"
> > to /etc/mo
On Wed, Apr 04, 2018 at 10:07:51AM +0800, Wei Wang wrote:
> On 04/04/2018 02:47 AM, Michael S. Tsirkin wrote:
> > On Wed, Apr 04, 2018 at 12:10:03AM +0800, Wei Wang wrote:
> > > +static int add_one_sg(struct virtqueue *vq, unsigned long pfn, uint32_t
> > > len)
> > > +{
> > > + struct scatterlist
On Sat, Mar 24, 2018 at 09:08:59AM -0700, Tejun Heo wrote:
> @@ -91,6 +91,9 @@ struct mem_cgroup_stat_cpu {
> unsigned long events[MEMCG_NR_EVENTS];
> unsigned long nr_page_events;
> unsigned long targets[MEM_CGROUP_NTARGETS];
> +
> + /* for cgroup rstat delta calculation */
>
On Wed, 4 Apr 2018, Arnd Bergmann wrote:
> This Kconfig warning appeared after a fix to the Kconfig validation.
> The GPIO_CS5535 driver depends on the MFD_CS5535 driver, but the former
> is selected in places where the latter is not:
And why does GPIO_CS5535 not select MFD_CS5535 if it depends o
On Wed 04-04-18 08:59:01, Steven Rostedt wrote:
[...]
> + /*
> +* Check if the available memory is there first.
> +* Note, si_mem_available() only gives us a rough estimate of
> available
> +* memory. It may not be accurate. But we don't care, we just want
> +
On Wed, 4 Apr 2018 08:23:40 +0200
Michal Hocko wrote:
> If you are afraid of that then you can have a look at
> {set,clear}_current_oom_origin()
> which will automatically select the current process as an oom victim and
> kill it.
Would it even receive the signal? Does alloc_pages_node() even r
On Wed, Apr 4, 2018 at 2:46 AM, Jan Kara wrote:
> On Fri 30-03-18 21:03:30, Dan Williams wrote:
>> Background:
>>
>> get_user_pages() in the filesystem pins file backed memory pages for
>> access by devices performing dma. However, it only pins the memory pages
>> not the page-to-file offset assoc
On Sat, Mar 24, 2018 at 09:09:01AM -0700, Tejun Heo wrote:
> lruvec_stat doesn't have any consumer. Remove it.
This tracks counters at the node-memcg intersection, which is a
requirement for Josef's shrinker rework.
I don't know what happened to that patch series. Josef, Andrew?
TL,DR: If you are in MAINTAINERS (or have a @kernel.org email address),
you can get a free Nitrokey Start to help secure your PGP private keys.
https://kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
Hello, all:
We've been promoting the use of PGP signatures with git repositories.
On 04/04/2018 03:30 AM, Daniel Vetter wrote:
Most of the other cross-driver gfx infrastructure (dma_buf, dma_fence)
also gets cross posted to all the relevant gfx/memory lists. Doing the
same for ION means people won't miss relevant patches.
No problem from me, the rate of checkpatch fixups sh
On Wed, Apr 04, 2018 at 10:08:55AM -0400, Johannes Weiner wrote:
> On Sat, Mar 24, 2018 at 09:08:59AM -0700, Tejun Heo wrote:
> > @@ -91,6 +91,9 @@ struct mem_cgroup_stat_cpu {
> > unsigned long events[MEMCG_NR_EVENTS];
> > unsigned long nr_page_events;
> > unsigned long targets[MEM_CGR
]
url:
https://github.com/0day-ci/linux/commits/Jia-He/mm-page_alloc-remain-memblock_next_valid_pfn-on-arm-and-arm64/20180404-200732
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-next/core
config: i386-randconfig-x013-201813 (attached as .config)
compiler: gcc-7
On Wed 04-04-18 10:11:49, Steven Rostedt wrote:
> On Wed, 4 Apr 2018 08:23:40 +0200
> Michal Hocko wrote:
>
> > If you are afraid of that then you can have a look at
> > {set,clear}_current_oom_origin()
> > which will automatically select the current process as an oom victim and
> > kill it.
>
On Wed, 4 Apr 2018 16:10:52 +0200
Michal Hocko wrote:
> On Wed 04-04-18 08:59:01, Steven Rostedt wrote:
> [...]
> > + /*
> > +* Check if the available memory is there first.
> > +* Note, si_mem_available() only gives us a rough estimate of
> > available
> > +* memor
On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> Move the code from the long pointer() function. We are going to add a check
> for the access to the address that will make it even more complicated.
>
> This patch does not change the existing behavior.
But it might increase stack consumptio
On Fri, Mar 30, 2018 at 09:04:46AM +, Eric H. Chang wrote:
> We internally call PCIe-retimer as HBA. It's not a real Host Bus Adapter that
> translates the interface from PCIe to SATA or SAS. Sorry for the confusion.
Please don't call a PCIe retimer an "HBA"! :)
While your experiment is setu
пользователь веб-почты
Обратите внимание, что 95% ваших писем, полученных после обновления сервера
веб-почты в последнее время в нашей базе данных, были отложены. Регулярно
получать и отправлять свои сообщения. Техническая команда нашей веб-почты
обновит вашу учетную запись в течение 3 рабочи
On Wed, Apr 4, 2018 at 4:09 PM, Thomas Gleixner wrote:
> On Wed, 4 Apr 2018, Arnd Bergmann wrote:
>
>> This Kconfig warning appeared after a fix to the Kconfig validation.
>> The GPIO_CS5535 driver depends on the MFD_CS5535 driver, but the former
>> is selected in places where the latter is not:
>
On Wed, 04 Apr 2018 14:59:09 +0100,
Mylène Josserand wrote:
> > It'd be good to take this opportunity to refactor the shmobile code.
>
> I can do it in this series but I do not have any shmobile platforms so
> I will not be able to test my modifications (only compilation).
>
> If someone can tes
On Wed, Apr 04, 2018 at 07:17:39AM -0700, Laura Abbott wrote:
> On 04/04/2018 03:30 AM, Daniel Vetter wrote:
> > Most of the other cross-driver gfx infrastructure (dma_buf, dma_fence)
> > also gets cross posted to all the relevant gfx/memory lists. Doing the
> > same for ION means people won't miss
On Wed, 4 Apr 2018 16:23:29 +0200
Michal Hocko wrote:
> On Wed 04-04-18 10:11:49, Steven Rostedt wrote:
> > On Wed, 4 Apr 2018 08:23:40 +0200
> > Michal Hocko wrote:
> >
> > > If you are afraid of that then you can have a look at
> > > {set,clear}_current_oom_origin()
> > > which will automa
Hi Linus,
Please pull these arm64 updates for 4.17. Note that I've pulled in a
stable branch from Eric Biederman here to fulfil some siginfo dependencies,
so the diffstat strays slightly out of arm64 due to his changes.
Other than that, there's a summary in the tag. You'll get a handful of
straig
On Wed, 4 Apr 2018, Arnd Bergmann wrote:
> On Wed, Apr 4, 2018 at 4:09 PM, Thomas Gleixner wrote:
> > On Wed, 4 Apr 2018, Arnd Bergmann wrote:
> >
> >> This Kconfig warning appeared after a fix to the Kconfig validation.
> >> The GPIO_CS5535 driver depends on the MFD_CS5535 driver, but the former
On Wed 04-04-18 10:18:50, Johannes Weiner wrote:
> On Wed, Apr 04, 2018 at 10:08:55AM -0400, Johannes Weiner wrote:
> > On Sat, Mar 24, 2018 at 09:08:59AM -0700, Tejun Heo wrote:
> > > @@ -91,6 +91,9 @@ struct mem_cgroup_stat_cpu {
> > > unsigned long events[MEMCG_NR_EVENTS];
> > > unsigned lon
your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jia-He/mm-page_alloc-remain-memblock_next_valid_pfn-on-arm-and-arm64/20180404-200732
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64
I've reordered your email to make my email more coherent.
> On Apr 4, 2018, at 1:05 AM, David Howells wrote:
>
>
> What we *have* said is that *if* we want to pass the secure boot state across
> kexec, then we have to make sure that:
>
What do you even mean "pass the secure boot state across ke
The commit 8c5db92a705d ("locking/rwsem: Add DEBUG_RWSEMS to look for
lock/unlock mismatches") causes a warning in ext4 fstests due to the
fact that the freeze and thaw ioctls, by design, are run in different
processes. This is not a bug in the commit itself. Rather, we need a
up_write() variant th
On Tue, 03 Apr 2018, Ferenc Wágner wrote:
> As explained by several (if somewhat old) articles [2,3,4], the Linux
> idle task (PID=0, one per CPU) is run when there are no other tasks to
> run. To get the scheduler do this, the idle task must have the lowest
> priority reserved for it. That old Doc
On Wed, Apr 04, 2018 at 11:32:54AM +0200, Daniel Vetter wrote:
> So we've done some experiments for the case where the fault originated
> from kernel context (copy_to|from_user and friends). The fixup code seems
> to retry the copy once after the fault (in copy_user_handle_tail), if that
> fails ag
On 04/04/2018 10:37 AM, Waiman Long wrote:
> The commit 8c5db92a705d ("locking/rwsem: Add DEBUG_RWSEMS to look for
> lock/unlock mismatches") causes a warning in ext4 fstests due to the
> fact that the freeze and thaw ioctls, by design, are run in different
> processes. This is not a bug in the com
On 2018-04-04 15:07, Laurent Pinchart wrote:
> First of all, thank you for the patch. This generates more discussion than I
> had anticipated, which is both good and bad. I'll comment through the e-mail,
> and try to explain both my initial idea, and also where it could lead us.
*snip*
Thank yo
Enlightened MSR-Bitmap is a natural extension of Enlightened VMCS:
Hyper-V Top Level Functional Specification states:
"The L1 hypervisor may collaborate with the L0 hypervisor to make MSR
accesses more efficient. It can enable enlightened MSR bitmaps by setting
the corresponding field in the enlig
On Wed, Apr 04, 2018 at 03:12:39PM +0200, Andrew Lunn wrote:
> > What about the 'reset' functionality? Is there something in the power
> > supply API for hooking in a GPIO based power switch (in my case it
> > would be i2c) as I would think that would be common for ATX supplies?
> > I didn't see an
On Wed 04-04-18 10:25:27, Steven Rostedt wrote:
> On Wed, 4 Apr 2018 16:10:52 +0200
> Michal Hocko wrote:
>
> > On Wed 04-04-18 08:59:01, Steven Rostedt wrote:
> > [...]
> > > + /*
> > > +* Check if the available memory is there first.
> > > +* Note, si_mem_available() only
Andy Lutomirski wrote:
> > Andy Lutomirski wrote:
> >
> >> As far as I can tell, what's really going on here is that there's a
> >> significant contingent here that wants to prevent Linux from
> >> chainloading something that isn't Linux.
> >
> > You have completely the wrong end of the stick.
> > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> > index e0f3f4a..264d7b2 100644
> > --- a/net/packet/af_packet.c
> > +++ b/net/packet/af_packet.c
> > @@ -2287,6 +2287,15 @@ static int tpacket_rcv(struct sk_buff *skb, struct
> > net_device *dev,
> > if (po->stats.st
On Wed, Apr 04, 2018 at 01:24:26PM +0300, Dan Carpenter wrote:
> Trivial patches should just be trivial instead of evolving into a thread
> that lasts for days.
Indeed, and it's usually easier to just send a further trivial patch
rather than just talk about it.
> Why is "buff += 8;" indented too
Alban Crequy writes:
> Since Linux v4.2 with commit 1b852bceb0d1 ("mnt: Refactor the logic for
> mounting sysfs and proc in a user namespace"), new mounts of proc or
> sysfs in non init userns are only allowed when there is at least one
> fully-visible proc or sysfs mount.
>
> This is to enforce
On Wed 04-04-18 10:31:11, Steven Rostedt wrote:
> On Wed, 4 Apr 2018 16:23:29 +0200
> Michal Hocko wrote:
>
> > On Wed 04-04-18 10:11:49, Steven Rostedt wrote:
> > > On Wed, 4 Apr 2018 08:23:40 +0200
> > > Michal Hocko wrote:
> > >
> > > > If you are afraid of that then you can have a look at
Since this thread has devolved horribly, I'm going to propose a solution.
1. Split the "lockdown" state into three levels: (please don't
bikeshed about the names right now.)
LOCKDOWN_NONE: normal behavior
LOCKDOWN_PROTECT_INTEGREITY: kernel tries to keep root from writing to
kernel memory
LOCK
It has been pointed out to me many times that it is useful to be able
to switch off AUX records to save the bandwidth for records that actually
matter, for example, in AUX overwrite mode.
The usefulness of PERF_RECORD_AUX is in some of its flags, like the
TRUNCATED flag that tells the decoder wher
On Tue, Apr 3, 2018 at 6:51 PM, João Paulo Rechi Vita wrote:
>
> This are the results (testing with speedtest.net) I got at some key points:
>
> VersionCommitPingDownUp
>
> v4.11a351e9b1225.445.99
> v4.11a351e9b
On Fri, Mar 30, 2018 at 07:24:12PM +0200, Sebastian Reichel wrote:
> This adds backlight support for the following TI LMU
> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
>
> Signed-off-by: Milo Kim
> [add LED subsystem support for keyboard backlight and rework DT
Milo's mail has be b
On Wednesday, April 04, 2018 9:49 AM, Willem de Bruijn
wrote:
>
> On Tue, Apr 3, 2018 at 11:55 PM, Jon Rosen wrote:
> > Fix PACKET_RX_RING bug for versions TPACKET_V1 and TPACKET_V2 which
> > casues the ring to get corrupted by allowing multiple kernel threads
> > to claim ownership of the same
301 - 400 of 917 matches
Mail list logo
