Since add_probe_trace_event() can reuse tf->tevs[i] after
calling clear_probe_trace_event(), this can make perf-probe
crash if the 1st attempt of probe event finding fails to find
an event argument, and the 2nd attempt fails to find probe point.
E.g.
$ perf probe -D "task_pid_nr tsk"
Failed to
Changes in v4
--
1. [old] abandon patch 4/4
2. [new] patch 4/7:
- return ZERO_SIZE_ALLOC instead 0 for zero sized requests
3. [new] patch 5/7:
- reorder kmalloc_info[], kmalloc_caches[] (in order of size)
- hard to split, so slightly larger
4. [new] patch 6/7:
- initialize kmalloc_c
There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
and KMALLOC_DMA.
The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
generated by kmalloc_cache_name().
This patch predefines the names of all types of km
The size of kmalloc can be obtained from kmalloc_info[],
so remove kmalloc_size() that will not be used anymore.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
include/linux/slab.h | 20
mm/slab.c| 5 +++--
mm/slab_common.c
The type of local variable *type* of new_kmalloc_cache() should
be enum kmalloc_cache_type instead of int, so correct it.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/m
The type of local variable *type* of new_kmalloc_cache() should
be enum kmalloc_cache_type instead of int, so correct it.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/m
Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
is not defined).
As suggested by Vlastimil Babka,
"Since you're doing these cleanups, have you considered reordering
kmalloc_info, size_index, kmalloc_index()
Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
is not defined).
As suggested by Vlastimil Babka,
"Since you're doing these cleanups, have you considered reordering
kmalloc_info, size_index, kmalloc_index()
In the current implementation, KMALLOC_RECLAIM is not initialized
until all the KMALLOC_NORMAL sizes have been initialized.
But for a particular size, create_kmalloc_caches() can be executed
faster by initializing different types of kmalloc in order.
$ ./scripts/bloat-o-meter vmlinux.old vmlinux.
This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
as the return value of zero sized requests.
Signed-off-by: Pengfei Li
---
include/linux/slab.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index
This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
as the return value of zero sized requests.
Signed-off-by: Pengfei Li
---
include/linux/slab.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index
In the current implementation, KMALLOC_RECLAIM is not initialized
until all the KMALLOC_NORMAL sizes have been initialized.
But for a particular size, create_kmalloc_caches() can be executed
faster by initializing different types of kmalloc in order.
$ ./scripts/bloat-o-meter vmlinux.old vmlinux.
KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
is initialized by different types of the same size.
So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
will benefit performance.
$ ./scripts/bloat-o-meter vmlinux.patch_1-6 vmlinux.patch_1-7
add/remove: 0/0 grow
KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
is initialized by different types of the same size.
So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
will benefit performance.
$ ./scripts/bloat-o-meter vmlinux.patch_1-6 vmlinux.patch_1-7
add/remove: 0/0 grow
On Fri 2019-09-13 14:04:57, Greg Kroah-Hartman wrote:
> [ Upstream commit 87ee613d076351950b74383215437f841ebbeb75 ]
>
> In most common cases VP index of a vcpu matches its vcpu index. Userspace is,
> however,
> free to set any mapping it wishes and we need to account for that when we
> need to
On Sun, Sep 15, 2019 at 09:34:37AM -0700, Randy Dunlap wrote:
> Kernel is 5.3-rc8 on x86_64.
>
> Loading and removing the pci-epf-test module causes a BUG.
Ugh... Could you try to reproduce it on earlier kernels?
On 15/09/2019 04:07, shikemeng wrote:
> From:
>
> reason: migration to invalid cpu in __set_cpus_allowed_ptr
> archive path: patches/euleros/sched
>
> Oops occur when running qemu on arm64:
> Unable to handle kernel paging request at virtual address 08effe40
> Internal error: Oops: 960
On Sat, Sep 14, 2019 at 11:56 PM Lennart Poettering
wrote:
>
> I am not expecting the kernel to guarantee entropy. I just expecting
> the kernel to not give me garbage knowingly. It's OK if it gives me
> garbage unknowingly, but I have a problem if it gives me trash all the
> time.
So realistical
Hi all,
Today's linux-next merge of the ia64 tree got a conflict in:
arch/ia64/hp/common/sba_iommu.c
between commit:
f9f3232a7d0ab73 ("dma-mapping: explicitly wire up ->mmap and ->get_sgtable")
from the dma-mapping tree and commit:
974f83ec1e5afee ("ia64: rework iommu probing")
from
From: Sanjay R Mehta
Signed-off-by: Sanjay R Mehta
---
drivers/ntb/hw/amd/ntb_hw_amd.c | 3 ++-
drivers/ntb/hw/amd/ntb_hw_amd.h | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index 2859cc9..e9286cf 100644
-
On Sun, Sep 15, 2019 at 7:32 AM Paul E. McKenney wrote:
>
> First, what am I looking for?
>
> I am looking for something that prevents the following:
>
> o Task A acquires a reference to Task B's task_struct while
> protected only by RCU, and is just about to increment ->rcu_users
>
There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
and KMALLOC_DMA.
The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
generated by kmalloc_cache_name().
This patch predefines the names of all types of km
Changes in v4
--
1. [old] abandon patch 4/4
2. [new] patch 4/7:
- return ZERO_SIZE_ALLOC instead 0 for zero sized requests
3. [new] patch 5/7:
- reorder kmalloc_info[], kmalloc_caches[] (in order of size)
- hard to split, so slightly larger
4. [new] patch 6/7:
- initialize kmalloc_c
In the current implementation, KMALLOC_RECLAIM is not initialized
until all the KMALLOC_NORMAL sizes have been initialized.
But for a particular size, create_kmalloc_caches() can be executed
faster by initializing different types of kmalloc in order.
$ ./scripts/bloat-o-meter vmlinux.old vmlinux.
The size of kmalloc can be obtained from kmalloc_info[],
so remove kmalloc_size() that will not be used anymore.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
include/linux/slab.h | 20
mm/slab.c| 5 +++--
mm/slab_common.c
From: Sanjay R Mehta
The AMD new hardware uses BAR23 and BAR45 as memory windows
as compared to previos where BAR1, BAR23 and BAR45 is used
for memory windows.
This patch add support for both AMD hardwares.
Signed-off-by: Sanjay R Mehta
---
drivers/ntb/hw/amd/ntb_hw_amd.c | 23 +++
Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
is not defined).
As suggested by Vlastimil Babka,
"Since you're doing these cleanups, have you considered reordering
kmalloc_info, size_index, kmalloc_index()
KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
is initialized by different types of the same size.
So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
will benefit performance.
$ ./scripts/bloat-o-meter vmlinux.patch_1-6 vmlinux.patch_1-7
add/remove: 0/0 grow
The type of local variable *type* of new_kmalloc_cache() should
be enum kmalloc_cache_type instead of int, so correct it.
Signed-off-by: Pengfei Li
Acked-by: Vlastimil Babka
Acked-by: Roman Gushchin
---
mm/slab_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/m
This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
as the return value of zero sized requests.
Signed-off-by: Pengfei Li
---
include/linux/slab.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index
On Sat, 2019-09-14 at 18:51 +0200, Christophe Leroy wrote:
>
> Le 14/09/2019 à 16:34, Scott Wood a écrit :
> > On Fri, 2019-08-23 at 12:50 +, Christophe Leroy wrote:
> > > On mpc83xx with a QE, IMMR is 2Mbytes.
> > > On mpc83xx without a QE, IMMR is 1Mbytes.
> > > Each driver will map a part o
Hi all,
Today's linux-next merge of the mips tree got a conflict in:
drivers/video/fbdev/Makefile
between commit:
c7b46e0c33c5946 ("fbdev: remove w90x900/nuc900 platform drivers")
from the arm-soc tree and commit:
e305bff3a706f58 ("video/fbdev: Drop JZ4740 driver")
from the mips tree.
Hello,
syzbot found the following crash on:
HEAD commit:3120b9a6 Merge tag 'ipc-fixes' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16b5c7fa60
kernel config: https://syzkaller.appspot.com/x/.config?x=861a6f31647968de
da
On Sun, 15 Sep 2019 07:24:20 PDT (-0700), m...@kernel.org wrote:
On Thu, 12 Sep 2019 22:40:34 +0100,
Darius Rad wrote:
Hi Darius,
As per the existing comment, irq_mask and irq_unmask do not need
to do anything for the PLIC. However, the functions must exist
(the pointers cannot be NULL) as
[ Added Lennart, who was active in the other thread ]
On Sat, Sep 14, 2019 at 10:22 PM Theodore Y. Ts'o wrote:
>
> Thus, add an optional configuration option which stops getrandom(2)
> from blocking, but instead returns "best efforts" randomness, which
> might not be random or secure at all.
So
On 9/4/19 9:06 AM, David Dai wrote:
> For high speed adapter like Mellanox CX-5 card, it can reach upto
> 100 Gbits per second bandwidth. Currently htb already supports 64bit rate
> in tc utility. However police action rate and peakrate are still limited
> to 32bit value (upto 32 Gbits per second).
Hi all,
Today's linux-next merge of the s390 tree got a conflict in:
arch/s390/configs/debug_defconfig
between commit:
3361f3193c747e8b ("s390: update configs")
from the s390-fixes tree and commit:
3c2eb6b76cabb7d9 ("s390/crypto: Support for SHA3 via CPACF (MSA6)")
from the s390 tree.
On Sun, Sep 15, 2019 at 10:53:00AM +0100, Jonathan Cameron wrote:
> On Sat, 14 Sep 2019 02:06:27 +0530
> Rohit Sarkar wrote:
>
> > Bcc:
> > Subject: [PATCH] staging: iio: adis16240: remove unused include
> > Reply-To:
> Something odd happened here with patch formatting. I fixed it up and
> app
"Paul E. McKenney" writes:
> So this looks good in and of itself, but I still do not see what prevents
> the unfortunate sequence of events called out in my previous email.
> On the other hand, if ->rcu and ->rcu_users were not allocated on top
> of each other by a union, I would be happy to prov
"Michael Kerrisk (man-pages)" writes:
> Hello Eric,
>
> On 9/11/19 1:06 AM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" writes:
>>
>>> Hello Christian,
>>>
> All: I plan to add the following text to the manual page:
>
>new_root and put_old may be the same dire
On Sun, 15 Sep 2019 18:31:33 +0100,
Palmer Dabbelt wrote:
Hi Palmer,
>
> On Sun, 15 Sep 2019 07:24:20 PDT (-0700), m...@kernel.org wrote:
> > On Thu, 12 Sep 2019 22:40:34 +0100,
> > Darius Rad wrote:
> >
> > Hi Darius,
> >
> >>
> >> As per the existing comment, irq_mask and irq_unmask do no
On Fri, Sep 13, 2019 at 5:21 PM Greg Kroah-Hartman
wrote:
>
> Feel free to also take that patch through any tree, it's "obviously
> correct" :)
OK :) Picked all 6 in compiler-attributes:
https://github.com/ojeda/linux/commits/compiler-attributes
I added Ingo's Acks and fixed a minor typo (h
ebied...@xmission.com (Eric W. Biederman) writes:
> "Paul E. McKenney" writes:
>
>> So this looks good in and of itself, but I still do not see what prevents
>> the unfortunate sequence of events called out in my previous email.
>> On the other hand, if ->rcu and ->rcu_users were not allocated on
On Fri, Sep 13, 2019 at 1:26 AM Joe Perches wrote:
>
> Not every project is going to use only the clang-format tool.
Why? The end goal would be to enforce all code to be running under the
same formatting rules (which, in practice, means the same tool at the
moment).
Note that you can use clang-f
On Sun, Sep 15, 2019 at 10:32:15AM -0700, Linus Torvalds wrote:
> * We will block for at most 15 seconds at a time, and if called
> * sequentially will decrease the blocking amount so that we'll
> * block for at most 30s total - and if people continue to ask
> * for blocking, at that point we'l
On Fri, Sep 06, 2019 at 04:17:59PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Sep 02, 2019 at 12:36:56PM -0500, Eric W. Biederman wrote:
> > Russell King - ARM Linux admin writes:
> >
> > > On Fri, Aug 30, 2019 at 04:02:48PM -0500, Eric W. Biederman wrote:
> > >> Russell King - ARM Li
I also wanted to ask, are we going to enforce the same strategy on
/dev/urandom ? If we don't because we fear application breakage or
whatever, then there will always be some incentive against migrating
to getrandom(). And if we do it, we know we have to take a reasonable
approach making the change
On Sun, Sep 15, 2019 at 2:43 PM Greg Kroah-Hartman
wrote:
>
> On Sat, Sep 14, 2019 at 10:08:35PM +0100, Okash Khawaja wrote:
> > On Mon, Sep 9, 2019 at 3:55 AM Gregory Nowak wrote:
> > >
> > > On Sun, Sep 08, 2019 at 10:43:02AM +0100, Okash Khawaja wrote:
> > > > Sorry, I have only now got round
From: Lucas A. M. Magalhaes
Add a virtual subdevice to simulate the flash control API.
Those are the supported controls:
v4l2-ctl -d /dev/v4l-subdev6 -L
Flash Controls
led_mode 0x009c0901 (menu) : min=0 max=2 default=0
value=0
0: Off
On Sun, Sep 15, 2019 at 10:07:24AM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 7:32 AM Paul E. McKenney wrote:
> >
> > First, what am I looking for?
> >
> > I am looking for something that prevents the following:
> >
> > o Task A acquires a reference to Task B's task_struct while
On Sun, Sep 15, 2019 at 01:25:02PM -0500, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > "Paul E. McKenney" writes:
> >
> >> So this looks good in and of itself, but I still do not see what prevents
> >> the unfortunate sequence of events called out in my previ
From: Alexandru Ardelean
Date: Thu, 12 Sep 2019 16:28:50 +0300
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index c141fe783e87..5b6213207c43 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/
From: zhong jiang
Date: Fri, 13 Sep 2019 00:59:02 +0800
> mlx5_unload_one do not need local variable to store different value,
> Hence just remove it.
>
> Signed-off-by: zhong jiang
Saeed, just take this directly via one of your trees.
Thank you.
On Sun, Sep 15, 2019 at 11:32 AM Willy Tarreau wrote:
>
> I think that the exponential decay will either not be used or
> be totally used, so in practice you'll always end up with 0 or
> 30s depending on the entropy situation
According to the systemd random-seed source snippet that Ahmed posted,
On Fri 2019-09-13 14:04:58, Greg Kroah-Hartman wrote:
> [ Upstream commit 72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc ]
>
> The state related to the VP assist page is still managed by the LAPIC
> code in the pv_eoi field.
I don't get it.
>
> +bool kvm_hv_assist_page_enabled(struct kvm_vcpu *vcpu)
On Sun, Sep 15, 2019 at 11:37 AM Willy Tarreau wrote:
>
> I also wanted to ask, are we going to enforce the same strategy on
> /dev/urandom ?
Right now the strategy for /dev/urandom is "print a one-line warning,
then do the read".
I don't see why we should change that. The whole point of urandom
On Sun, Sep 15, 2019 at 11:59:41AM -0700, Linus Torvalds wrote:
> > In addition, since you're leaving the door open to bikeshed around
> > the timeout valeue, I'd say that while 30s is usually not huge in a
> > desktop system's life, it actually is a lot in network environments
> > when it delays a
Hi, RMS and Bruce Perens;
I noticed that recently Grsecurity's Brad Spengler (who sued you, Bruce,
for speaking the truth), decided to "Flex" and basically advertise while
chastising the linux community:
news.ycombinator.com/item?id=20874470
Another poster then pointed out the history of Gr
On Sun, Sep 15, 2019 at 12:08:31PM -0700, Linus Torvalds wrote:
> My suggested patch left the /dev/random blocking behavior, because
> hopefully people *know* about the problems there.
>
> And hopefully people understand that getrandom(GRND_RANDOM) has all
> the same issues.
I think this one does
On 9/6/19 11:42 PM, Shuah Khan wrote:
> After practically re-writing the driver to collpase it into a monolith,
> I am adding myself as a reviewer for vimc driver.
Thank you!
>
> Signed-off-by: Shuah Khan
Acked-by: Helen Koike
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
On 9/6/19 11:42 PM, Shuah Khan wrote:
> If vimc module is removed while streaming is in progress, sensor subdev
> unregister runs into general protection fault when it tries to unregister
> media entities. This is a common subdev problem related to releasing
> pads from v4l2_device_unregister_su
On 9/6/19 11:42 PM, Shuah Khan wrote:
> vimc driver is now a monolithic driver. Update the module parameter
> usage information to reflect that.
>
> Signed-off-by: Shuah Khan
Acked-by: Helen Koike
> ---
> Documentation/media/v4l-drivers/vimc.rst | 12 ++--
> 1 file changed, 6 inser
Hi Shuah,
Thanks for the patch.
On 9/6/19 11:42 PM, Shuah Khan wrote:
> vimc uses Component API to split the driver into functional components.
> The real hardware resembles a monolith structure than component and
> component structure added a level of complexity making it hard to
> maintain with
Hi Shuah,
On 9/6/19 11:42 PM, Shuah Khan wrote:
> Move duplicated IS_SRC and IS_SINK dfines to common header. Rename
> them to VIMC_IS_SRC and VIM_IS_SINK.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/platform/vimc/vimc-common.h | 4
> drivers/media/platform/vimc/vimc-debayer.c |
'pih' is known to be non-NULL at this point, so the test can be removed.
Signed-off-by: Christophe JAILLET
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
b/
On Sun, Sep 15, 2019 at 12:18 PM Willy Tarreau wrote:
>
> Oh no I definitely don't want this behavior at all for urandom, what
> I'm saying is that as long as getrandom() will have a lower quality
> of service than /dev/urandom for non-important randoms
Ahh, here you're talking about the fact tha
On 9/15/19 2:40 AM, KP Singh wrote:
> On 15-Sep 00:33, Yonghong Song wrote:
>>
>>
>> On 9/10/19 12:55 PM, KP Singh wrote:
>>> From: KP Singh
>>>
>>> Adds a callback which is called when a new program is attached
>>> to a hook. The callback registered by the process_exection hook
>>> checks if a
Hi all,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/riscv/boot-image-header.rst
between commit:
474efecb65dceb15f ("riscv: modify the Image header to improve compatibility
with the ARM64 header")
from the riscv tree and commit:
638b642f82bb8ee81 ("docs
On 9/15/19 9:39 AM, Al Viro wrote:
> On Sun, Sep 15, 2019 at 09:34:37AM -0700, Randy Dunlap wrote:
>> Kernel is 5.3-rc8 on x86_64.
>>
>> Loading and removing the pci-epf-test module causes a BUG.
>
> Ugh... Could you try to reproduce it on earlier kernels?
>
Sure... will get back to you.
--
~
On Sun, Sep 15, 2019 at 12:31:42PM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 12:18 PM Willy Tarreau wrote:
> >
> > Oh no I definitely don't want this behavior at all for urandom, what
> > I'm saying is that as long as getrandom() will have a lower quality
> > of service than /dev/uran
We have an interrupt handler for the wake-up GPIO pin, but we're missing
the code to wake-up the system. This can cause timeouts receiving data
for the UART that shares the wake-up GPIO pin with the USB PHY.
All we need to do is just wake the system and kick the autosuspend
timeout to fix the issu
Lad, Prabhakar wrote on Sat [2019-Sep-14 11:11:02
+0100]:
> Hi Benoit,
>
> Thank you for the patch.
>
> On Thu, Sep 12, 2019 at 1:58 PM Benoit Parrot wrote:
> >
> > Add powerdown-gpios to the list of optional properties for the OV2659
> > camera sensor.
> >
> > Signed-off-by: Benoit Parrot
>
On Sun, Sep 15, 2019 at 09:01:30PM +0200, Pavel Machek wrote:
On Fri 2019-09-13 14:04:58, Greg Kroah-Hartman wrote:
[ Upstream commit 72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc ]
The state related to the VP assist page is still managed by the LAPIC
code in the pv_eoi field.
I don't get it.
+
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/bluetooth/btusb.c
between commit:
1ffdb51f28e8ec ("Revert "Bluetooth: btusb: driver to enable the usb-wakeup
feature"")
from Linus' tree and commit:
9e45524a011107 ("Bluetooth: btusb: Fix suspend issue for
Lad, Prabhakar wrote on Sat [2019-Sep-14 11:33:42
+0100]:
> Hi Benoit,
>
> On Thu, Sep 12, 2019 at 1:58 PM Benoit Parrot wrote:
> >
> > On some board it is possible that the sensor 'powerdown'
> > pin might be controlled with a gpio instead of being
> > tied to always powered.
> >
> > This patc
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
between commit:
bf280c0387ebbf8ee ("ixgbe: fix double clean of Tx descriptors with xdp")
from Linus' tree and commit:
5c129241e2de79f09 ("ixgbe: add support for AF_XDP n
Could someone please review this?
On 2019-09-04 03:15, Jethro Beekman wrote:
> Some flash controllers don't have a software sequencer. Avoid
> configuring the register addresses for it, and double check
> everywhere that its not accidentally trying to be used.
>
> Every use of `sregs` is now guar
Modify the scaler subdevice to accept setting the resolution of the source
pad (previously the source resolution would always be 3 times the sink for
both dimensions). Now any resolution can be set at src (even smaller ones)
and the sink video will be scaled to match it.
Test example: With the vim
On Mon, 16 Sep 2019, Pengfei Li wrote:
> There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
> and KMALLOC_DMA.
>
> The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
> but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
> generated by kmalloc_cache_name().
On Mon, 16 Sep 2019, Pengfei Li wrote:
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 2aed30deb071..e7903bd28b1f 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1165,12 +1165,9 @@ void __init setup_kmalloc_cache_index_table(void)
> size_index[size_index_ele
On Mon, 16 Sep 2019, Pengfei Li wrote:
> Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
> is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
> is not defined).
>
> As suggested by Vlastimil Babka,
>
> "Since you're doing these cleanups, have you considered
On Mon, 16 Sep 2019, Pengfei Li wrote:
> The type of local variable *type* of new_kmalloc_cache() should
> be enum kmalloc_cache_type instead of int, so correct it.
>
> Signed-off-by: Pengfei Li
> Acked-by: Vlastimil Babka
> Acked-by: Roman Gushchin
Acked-by: David Rientjes
On Mon, 16 Sep 2019, Pengfei Li wrote:
> The size of kmalloc can be obtained from kmalloc_info[],
> so remove kmalloc_size() that will not be used anymore.
>
> Signed-off-by: Pengfei Li
> Acked-by: Vlastimil Babka
> Acked-by: Roman Gushchin
Acked-by: David Rientjes
On Mon, 16 Sep 2019, Pengfei Li wrote:
> This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
> as the return value of zero sized requests.
>
> Signed-off-by: Pengfei Li
Acked-by: David Rientjes
On Mon, 16 Sep 2019, Pengfei Li wrote:
> KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
> is initialized by different types of the same size.
>
> So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
> will benefit performance.
>
> $ ./scripts/bloat-o-meter vm
zswap_writeback_entry() maps a handle to read swpentry first, and
then in the most common case it would map the same handle again.
This is ok when zbud is the backend since its mapping callback is
plain and simple, but it slows things down for z3fold.
Since there's hardly a point in unmapping a ha
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/dml/Makefile
between commit:
54b8ae66ae1a345 ("kbuild: change *FLAGS_.o to take the path
relative to $(obj)")
from the kbuild tree and commits:
0f0727d971f6fdf ("drm/amd/display: readd -m
On Thu, Aug 29, 2019 at 2:50 AM Gustavo A. R. Silva
wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct ubifs_zno
So we've had a fairly quiet last week, but I think it was good that we
ended up having that extra week and the final rc8.
Even if the reason for that extra week was my travel schedule rather
than any pending issues, we ended up having a few good fixes come in,
including some for some bad btrfs beh
On Fri, Aug 16, 2019 at 10:01 AM chengzhihao wrote:
>
> > ubifs_assert(c, p < c->gap_lebs + c->lst.idx_lebs);
>
> I've done 50 problem reproduces on different flash devices and made sure that
> the assertion was not triggered. See record.txt for details.
Thanks for letting me know. :)
I need to
Hi all,
Today's linux-next merge of the modules tree got a conflict in:
scripts/Makefile.modpost
between commit:
9b9a3f20cbe0ba ("kbuild: split final module linking out into
Makefile.modfinal")
from the kbuild tree and commit:
eb8305aecb958e ("cripts: Coccinelle script for namespace de
Hi Linus,
Please pull hwmon updates for Linux v5.4 from signed tag:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-for-v5.4
Thanks,
Guenter
--
The following changes since commit a55aa89aab90fae7c815b0551b07be37db359d76:
Linux 5.3-rc6 (2019-08-25 12:01:2
Hello, Maintainer(Russell King)...
Would you please update the feedback for this patch?
2019년 9월 11일 (수) 오후 11:16, Austin Kim 님이 작성:
>
> Since rel->r_offset is declared as Elf32_Addr,
> this value is always non-negative.
> typedef struct elf32_rel {
> Elf32_Addrr_offset;
> Elf32_Word r_in
Hi all,
Today's linux-next merge of the modules tree got a conflict in:
include/linux/export.h
between at least commit:
69a94abb82eed ("export.h, genksyms: do not make genksyms calculate CRC of
trimmed symbols")
from the compiler-attributes tree and commit:
cb9b55d21fe06 ("module: add
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4 (2019-08-11 13:26:41 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
tags/regmap-v5.4
for you to fetch changes up to 1bd4584626a97156
Hi Alexandre, thanks for the thoughts.
On Thu, Sep 12, 2019 at 9:09 AM Alexandre Belloni
wrote:
>
> Hi Nick,
>
> On 10/09/2019 16:19:29+0100, Nick Crews wrote:
> > Check that the time received from the RTC HW is valid,
> > otherwise the computation of rtc_year_days() in the next
> > line could, a
Hi all,
Today's linux-next merge of the block tree got a conflict in:
block/blk-settings.c
include/linux/blkdev.h
between commit:
45147fb522bb459e7 ("block: add a helper function to merge the segments")
from the dma-mapping tree and commit:
68c43f133a754cbf5 ("block: Introduce elevato
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
tags/regulator-v5.4
for you to fetch changes up to c4ad85026d
On Fri, Sep 13, 2019 at 03:13:26PM -0400, Alan Stern wrote:
> On Thu, 12 Sep 2019, Paul E. McKenney wrote:
>
> > On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
>
> > > To this end, the LKMM imposes three extra restrictions, together
> > > called the "plain-coherence" axiom because of
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.4
for you to fetch changes up to b769c5ba8aedc395ed04abe
101 - 200 of 290 matches
Mail list logo
