Hi Matti,
I love your patch! Perhaps something to improve:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on regulator/for-next abelloni/rtc-next v5.11-rc2
next-20210108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Fri, Jan 08, 2021 at 07:58:13AM -0800, Shakeel Butt wrote:
> This patch adds swapcache stat for the cgroup v2. The swapcache
> represents the memory that is accounted against both the memory and the
> swap limit of the cgroup. The main motivation behind exposing the
> swapcache stat is for
On Fri, Jan 8, 2021 at 1:59 PM Andy Lutomirski wrote:
>
> The implementation was rather buggy. It unconditionally marked PTEs
> read-only, even for VM_SHARED mappings. I'm not sure whether this is
> actually a problem, but it certainly seems unwise. More importantly, it
> released the mmap
On Fri, Jan 8, 2021 at 9:53 AM Andrea Arcangeli wrote:
>
> Do you intend to eventually fix the zygote vmsplice case or not?
> Because in current upstream it's not fixed currently using the
> enterprise default config.
Is this the hugepage case? Neither of your patches actually touched
that, so
On 1/8/21 11:19 AM, Phillip Susi wrote:
> Does anyone know where you can report issues on lkml.org? There's a
> link to have it forward you a copy of mail but it has a capcha and the
> capha is broken.
>
Historically it has been: Jasper Spaans
Note that most of us are moving away from
On Fri, Jan 8, 2021 at 10:55 AM Andy Lutomirski wrote:
>
> I can't find any users at all of this mechanism, so just remove it.
Ack, as long as it sits in linux-next for a while.
Linus
Does anyone know where you can report issues on lkml.org? There's a
link to have it forward you a copy of mail but it has a capcha and the
capha is broken.
> Could we pause this madness? Scrollback is still useful. I needed it
> today... it was too small, so command results I was looking for
> already scrolled away, but... life will be really painful with 0
> scrollback.
> You'll need it, too... as soon as you get oops and will want to see
> errors
On Fri, Jan 8, 2021 at 4:26 AM Felipe Balbi wrote:
>
>
> Hi,
>
> John Stultz writes:
> > From: Yu Chen
> >
> > Just resending this, as discussion died out a bit and I'm not
> > sure how to make further progress. See here for debug data that
> > was requested last time around:
> >
> >
On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren wrote:
>
> * Doug Anderson [201204 16:43]:
> > Hi,
> >
> > On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade wrote:
> > >
> > > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers
> > > > > that existed in v4.4")
> > > >
> > > >
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210108
x86_64 randconfig-a006-20210108
x86_64 randconfig-a001-20210108
x86_64 randconfig-a002-20210108
x86_64
On Fri, Jan 08, 2021 at 10:55:00AM +0100, Christoph Hellwig wrote:
> It happens on a dax_device. We should not interwind dax and block_device
> even more after a lot of good work has happened to detangle them.
I agree that the dax device should not be implied from the block device,
but what
On Fri, Jan 08, 2021 at 05:52:11PM +0800, Ruan Shiyang wrote:
>
>
> On 2021/1/5 上午7:34, Darrick J. Wong wrote:
> > On Fri, Dec 18, 2020 at 10:11:54AM +0800, Ruan Shiyang wrote:
> > >
> > >
> > > On 2020/12/16 上午4:51, Darrick J. Wong wrote:
> > > > On Tue, Dec 15, 2020 at 08:14:13PM +0800,
On Fri 08 Jan 06:04 CST 2021, Robert Foss wrote:
> This driver supports multiple architecture versions of the Qualcomm ISP.
> The CAMSS architecure which this driver is name after, and with the
> introduction of this series, the Titan architecture.
>
> The ISPIF is IP-block that is only present
On Fri, Jan 8, 2021 at 9:45 AM Petr Mladek wrote:
>
> Feel free to push v2 directly.
Thanks, done.
Linus
On Fri, Jan 8, 2021 at 10:19 AM Jason Gunthorpe wrote:
>
> Sorry, I missed something, how does mmaping a fresh new page in the
> child impact the parent?
>
> I guess the issue is not to mmap but to GUP a shared page
No.
It has nothing to do with a shared page.
The problem with the COW in the
On Fri, Jan 08, 2021 at 02:50:35PM +0100, Vlastimil Babka wrote:
> On 1/6/21 2:17 AM, paul...@kernel.org wrote:
> > From: "Paul E. McKenney"
> >
> > There are kernel facilities such as per-CPU reference counts that give
> > error messages in generic handlers or callbacks, whose messages are
> >
On Wed, Jan 06, 2021 at 02:21:14PM +0900, Masami Hiramatsu wrote:
> So I think it is possible to introduce a keyword in a comment
> for ignoring sync check something like below. This will allow us
> a generic pattern matching.
>
> The keyword is just an example, "no-sync-check" etc. is OK.
>
>
Hi Linus,
Please pull the following KUnit fixes update for Linux 5.11-rc3.
This kunit update for Linux 5.11-rc3 consists one fix to force the use
of the 'tty' console for UML. Given that kunit tool requires the console
output, explicitly stating the dependency makes sense than relying on
it
On Fri, Jan 8, 2021 at 5:09 AM Walter Wu wrote:
>
> CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> instrumentation, but we should only need one config, so that we remove
> CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
>
> When enable KASAN
The implementation was rather buggy. It unconditionally marked PTEs
read-only, even for VM_SHARED mappings. I'm not sure whether this is
actually a problem, but it certainly seems unwise. More importantly, it
released the mmap lock before flushing the TLB, which could allow a racing
CoW
On Fri 08 Jan 06:04 CST 2021, Robert Foss wrote:
> Comment refers to ISPIF, but this is incorrect. Only
> the VFE interrupts are handled by this function.
>
> Signed-off-by: Robert Foss
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/media/platform/qcom/camss/camss-vfe-4-1.c |
On Fri, Jan 08, 2021 at 11:26:53AM +0100, Arnd Bergmann wrote:
> On Fri, Jan 8, 2021 at 10:33 AM Will Deacon wrote:
> > On Fri, Jan 08, 2021 at 10:19:56AM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > With UBSAN enabled and building with clang, there are occasionally
> > >
On Fri 08 Jan 06:04 CST 2021, Robert Foss wrote:
> Function name is comment is wrong, and was changed to be
> the same as the actual function name.
>
> Signed-off-by: Robert Foss
> ---
> drivers/media/platform/qcom/camss/camss-vfe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On 1/8/21 9:45 AM, Petr Mladek wrote:
> On Thu 2021-01-07 11:38:36, Linus Torvalds wrote:
>> On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
>> wrote:
>>> Linus, can you take this directly, or is this going through some other
>>> tree?
>> I was _assuming_ that I'd get it through the normal
I am ok with you as a slab maintainer. I have seen some good work from
you.
Acked-by: Christoph Lameter
On Fri, 8 Jan 2021 at 19:31, Andrey Konovalov wrote:
>
> On Sun, Jan 3, 2021 at 6:12 PM Lecopzer Chen wrote:
> >
> > Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> > ("kasan: support backing vmalloc space with real shadow memory")
> >
> > Acroding to how x86 ported it [1], they
On Fri 08 Jan 01:57 CST 2021, Vinod Koul wrote:
> Hi Bjorn,
>
> On 07-01-21, 11:17, Bjorn Andersson wrote:
> > On Tue 05 Jan 23:49 CST 2021, Vinod Koul wrote:
> > > +#PIN CONFIGURATION NODES
> > > +patternProperties:
> > > + '-pinmux$':
> >
> > I believe that what Rob was asking for was the
On Fri, Jan 8, 2021 at 10:31 AM Andy Lutomirski wrote:
>
> Can we just remove vmsplice() support? We could make it do a normal
> copy, thereby getting rid of a fair amount of nastiness and potential
> attacks. Even ignoring issues relating to the length of time that the
> vmsplice reference is
On Sun, Jan 3, 2021 at 6:12 PM Lecopzer Chen wrote:
>
> Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> but in arm64 I just simulate how
> -Original Message-
> From: Paul Thomas
> Sent: Friday, January 8, 2021 9:27 PM
> To: Radhey Shyam Pandey
> Cc: Dan Williams ; Vinod Koul
> ; Michal Simek ; Matthew Murrian
> ; Romain Perier
> ; Krzysztof Kozlowski ; Marc
> Ferland ; Sebastian von Ohr
> ; dmaeng...@vger.kernel.org;
The AD5766/AD5767 are 16-channel, 16-bit/12-bit, voltage output dense DACs
Digital-to-Analog converters.
This change adds support for these DACs.
Signed-off-by: Cristian Pop
---
Changelog v5:
- Remove explicit init in "ad5766_span_tbl"
- Check the return value of
New interface is proposed for dither functionality. This future allows
composing an external signals to the selected output channel.
The dither signal can be turned on/off, scaled, inverted, or it can be
selected from different sources.
Signed-off-by: Cristian Pop
---
Changelog v5:
This adds device tree bindings for the AD5766 DAC.
Signed-off-by: Cristian Pop
---
Changelog v5:
-rename to property to "output-range-voltage"
.../bindings/iio/dac/adi,ad5766.yaml | 64 +++
1 file
Prefer using ftrace over function entry/exit logging messages.
Warn with various function entry/exit only logging that only
use __func__ with or without descriptive decoration.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 35 +++
1 file changed, 35
On Fri, Jan 8, 2021 at 10:19 AM Jason Gunthorpe wrote:
>
> On Fri, Jan 08, 2021 at 12:00:36PM -0500, Andrea Arcangeli wrote:
> > > The majority cannot be converted to notifiers because they are DMA
> > > based. Every one of those is an ABI for something, and does not expect
> > > extra privilege
On Fri, Jan 8, 2021 at 7:45 AM Adam Ford wrote:
>
> On Fri, Jan 8, 2021 at 1:22 AM Tony Lindgren wrote:
> >
> > * H. Nikolaus Schaller [201230 13:29]:
> > > > Am 30.12.2020 um 13:55 schrieb Adam Ford :
> > > > On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren wrote:
> > > >>
> > > >> At least for
On Sun, Jan 3, 2021 at 6:12 PM Lecopzer Chen wrote:
>
> Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> ("kasan: support backing vmalloc space with real shadow memory")
>
> Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> but in arm64 I just simulate how
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20210108
x86_64 randconfig-a006-20210108
x86_64
On Sun, Jan 3, 2021 at 6:13 PM Lecopzer Chen wrote:
>
> Now I have no device to test for HW_TAG, so keep it not selected
> until someone can test this.
>
> Signed-off-by: Lecopzer Chen
> ---
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig
Hello RT Folks!
I'm pleased to announce the 4.19.165-rt70 stable release.
This release is just an update to the new stable 4.19.165
version and no RT specific changes have been made.
You can get this release via the git tree at:
On Sun, Jan 3, 2021 at 2:56 PM Lecopzer Chen wrote:
>
> During testing kasan_populate_early_shadow and kasan_remove_zero_shadow,
> if the shadow start and end address in kasan_remove_zero_shadow() is
> not aligned to PMD_SIZE, the remain unaligned PTE won't be removed.
>
> In the test case for
On Sun, Jan 3, 2021 at 7:39 AM Lecopzer Chen wrote:
>
> kasan_remove_zero_shadow() shall use original virtual address, start
> and size, instead of shadow address.
>
> Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work
> with KASAN")
> Signed-off-by: Lecopzer Chen
> ---
>
On Fri, Jan 08, 2021 at 10:51:55AM +0800, DENG Qingfang wrote:
> This was for OpenWrt's swconfig driver, which never made it upstream,
> and was also superseded by MT7530 DSA driver.
What about
Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt ?
Should that also be removed?
On Fri, Jan 08, 2021 at 12:00:36PM -0500, Andrea Arcangeli wrote:
> > The majority cannot be converted to notifiers because they are DMA
> > based. Every one of those is an ABI for something, and does not expect
> > extra privilege to function. It would be a major breaking change to
> > have
On Fri, Jan 08, 2021 at 11:17:25AM +0530, Sai Prakash Ranjan wrote:
> On 2021-01-07 22:27, isa...@codeaurora.org wrote:
> > On 2021-01-06 03:56, Will Deacon wrote:
> > > On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
> > > > commit ecd7274fb4cd ("iommu: Remove unused
Hi Chenyi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v5.11-rc2 next-20210108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618 gpu.
Signed-off-by: Akhil P Oommen
---
Changes
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index
The kernel test robot reports the following warning.
drivers/spi/spi-cadence-quadspi.c:966:24: warning: comparison of distinct
pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (500UL) *'
(aka 'unsigned long *')) [-Wcompare-distinct-pointer-types]
Hi, Shiyang,
On 12/18/2020 1:13 AM, Ruan Shiyang wrote:
So I tried the patchset with pmem error injection, the SIGBUS payload
does not look right -
** SIGBUS(7): **
** si_addr(0x(nil)), si_lsb(0xC), si_code(0x4, BUS_MCEERR_AR) **
I expect the payload looks like
** si_addr(0x7f3672e0),
Hi Linus,
Please pull the following fixes update for Linux 5.11-rc3.
This fixes update for 5.11-rc3 consists of two minor fixes to vDSO test
changes in 5.11-rc1 update.
diff is attached.
thanks,
-- Shuah
The following changes
On Fri, Jan 8, 2021 at 3:12 AM Christopher William Snowhill
wrote:
>
> There appears to be a regression with the filesystem NLS modules. I cannot
> load any of them. They all produce:
>
> modprobe: ERROR: could not insert 'nls_cp437': Invalid argument
>
> The system journal reports:
>
> Jan 08
Hi James,
I have tested this with OpenCSD v1.0.0 + Linux 5.11-rc2.
Reviewed-by: Mike Leach
Tested-by: Mike Leach
On Fri, 8 Jan 2021 at 14:28, James Clark wrote:
>
> Replace the OCSD_INSTR switch statement with an if to
> fix compilation error about unhandled values and avoid
> this issue
On Tue, Dec 22, 2020 at 05:53:11PM -0800, Chang S. Bae wrote:
> The kernel pushes data on the userspace stack when entering a signal. If
> using a sigaltstack(), the kernel precisely knows the user stack size.
^^^
Formulate properly.
>
> When the kernel knows that the user
On 2021-01-07 21:47, Sai Prakash Ranjan wrote:
On 2021-01-07 22:27, isa...@codeaurora.org wrote:
On 2021-01-06 03:56, Will Deacon wrote:
On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY
flag")
removed unused
From: Rafael J. Wysocki
On x86 scale invariace tends to be disabled during resume from
suspend-to-RAM, because the MPERF or APERF MSR values are not as
expected then due to updates taking place after the platform
firmware has been invoked to complete the suspend transition.
That, of course, is
On Tue, Dec 22, 2020 at 05:53:12PM -0800, Chang S. Bae wrote:
> +static int setup_altstack(void *start, unsigned long size)
> +{
> + stack_t ss;
> +
> + memset(, 0, sizeof(ss));
> + ss.ss_size = size;
> + ss.ss_sp = start;
> +
> + return sigaltstack(, NULL);
> +}
> +
> +static
On Fri, Jan 08, 2021 at 09:26:40AM -0700, Jens Axboe wrote:
> >> Can you show the callers that DO NOT need it?
> >
> > OK, so here's my suggestion:
> >
> > 1) For 5.11, we just re-instate the task_work run in get_signal(). This
> >will make TWA_RESUME have the exact same behavior as before.
I just noticed that we have raw_spin_lock_bh() and it has a few users.
My guess is that the API should be removed and the existing user(s)
should be moved to spin_lock_bh() / spinlock_t instead.
On !RT it works as expected and there is no difference compared to
spinlock_t.
On RT it is kind of
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
devprop-5.11-rc3
with top-most commit 3f7bddaf5d5a83aa2eb1e6d72db221d3ec43c813
device property: add description of fwnode cases
on top of commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
On Fri, Jan 08, 2021 at 09:39:56AM -0800, Linus Torvalds wrote:
> page_count() is simply the right and efficient thing to do.
>
> You talk about all these theoretical inefficiencies for cases like
> zygote and page pinning, which have never ever been seen except as a
> possible attack vector.
Do
Hi Doug,
On Wed, Jan 6, 2021 at 2:35 AM Doug Anderson wrote:
>
> Benjamin,
>
> On Fri, Dec 11, 2020 at 2:24 PM Douglas Anderson
> wrote:
> >
> > The goal of this series is to support the Goodix GT7375P touchscreen.
> > This touchscreen is special because it has power sequencing
> >
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-5.11-rc3
with top-most commit c4151604f0603d5700072183a05828ff87d764e4
cpufreq: intel_pstate: remove obsolete functions
on top of commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-5.11-rc3
with top-most commit 24e8ab6886d80fe60b1d4e64b6d9f15ea9ad597a
Merge branches 'acpi-scan' and 'acpi-misc'
on top of commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
Linux
Hi,
On Mon, Dec 21, 2020 at 8:01 AM Maulik Shah wrote:
>
> Hi Doug,
>
> On 12/12/2020 3:45 AM, Douglas Anderson wrote:
> > In Linux, if a driver does disable_irq() and later does enable_irq()
> > on its interrupt, I believe it's expecting these properties:
> > * If an interrupt was pending when
On Thu 2021-01-07 11:38:36, Linus Torvalds wrote:
> On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
> wrote:
> >
> > Linus, can you take this directly, or is this going through some other
> > tree?
>
> I was _assuming_ that I'd get it through the normal printk pull
> request, it doesn't seem
On Thu, Jan 07, 2021 at 03:33:55PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.6 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Jan 8, 2021 at 8:14 AM Andrea Arcangeli wrote:
>
> page_count in do_wp_page is a fix for the original security issue
Not just that.
page_count() is simply the right and efficient thing to do.
You talk about all these theoretical inefficiencies for cases like
zygote and page pinning,
On Thu, Jan 07, 2021 at 03:33:19PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.88 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jan 07, 2021 at 03:32:00PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.166 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jan 07, 2021 at 03:31:15PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.214 release.
> There are 29 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jan 07, 2021 at 03:31:19PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.250 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Jan 07, 2021 at 03:31:33PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.250 release.
> There are 33 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Jan 08, 2021 at 04:35:57PM +0100, Vlastimil Babka wrote:
> On 1/8/21 1:26 AM, Paul E. McKenney wrote:
> > On Wed, Jan 06, 2021 at 03:42:12PM -0800, Paul E. McKenney wrote:
> >> On Wed, Jan 06, 2021 at 01:48:43PM -0800, Andrew Morton wrote:
> >> > On Tue, 5 Jan 2021 17:16:03 -0800 "Paul E.
In Linux, if a driver does disable_irq() and later does enable_irq()
on its interrupt, I believe it's expecting these properties:
* If an interrupt was pending when the driver disabled then it will
still be pending after the driver re-enables.
* If an edge-triggered interrupt comes in while an
In commit 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for
msm gpio") we tried to Ack interrupts during unmask. However, that
patch forgot to check "intr_ack_high" so, presumably, it only worked
for a certain subset of SoCs.
Let's add a small accessor so we don't need to open-code the
When the Qualcomm pinctrl driver wants to Ack an interrupt, it does a
read-modify-write on the interrupt status register. On some SoCs it
makes sure that the status bit is 1 to "Ack" and on others it makes
sure that the bit is 0 to "Ack". Presumably the first type of
interrupt controller is a
There's currently a comment in the code saying function 0 is GPIO.
Instead of hardcoding it, let's add a member where an SoC can specify
it. No known SoCs use a number other than 0, but this just makes the
code clearer. NOTE: no SoC code needs to be updated since we can rely
on
> -Original Message-
> From: Barnabás Pőcze
> Sent: 2021年1月8日 0:04
> To: Hans de Goede
> Cc: Yuan, Perry; mgr...@linux.intel.com; platform-driver-
> x...@vger.kernel.org; linux-kernel@vger.kernel.org; Limonciello, Mario
> Subject: Re: [PATCH v2 1/2] platform/x86: dell-privacy: Add
config: openrisc-randconfig-m031-20210108 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/accessibility/speakup/serialio.c:54 spk_serial_init() warn: always true
condition
The following changes since commit
5c8fe583cce542aa0b84adc939ce85293de36e5e:
Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
are available in the Git repository at:
git://git.lwn.net/linux.git tags/docs-5.11-3
for you to fetch changes up to 9d54ee78aef62c29b15ae2f58a70b1d1cd63a8f0:
docs:
On Fri, Jan 8, 2021 at 4:48 AM Will Deacon wrote:
>
> It certainly looks simple and correct to me, although it means we're now
> taking the mmap sem for write in the case where we only want to clear the
> access flag, which should be fine with the thing only held for read, no?
When I was looking
Hi Andrey,
On 1/8/21 1:36 PM, Andrey Konovalov wrote:
> Perhaps we could add a generic arch-agnostic enum to
> include/linux/kasan.h and use it in both arm64 and KASAN code?
>
> enum kasan_hw_tags_mode {
> KASAN_HW_TAGS_SYNC,
> KASAN_HW_TAGS_ASYNC
> }
>
> Assuming other architectures that
On Fri, Jan 8, 2021 at 12:16 AM Michael Walle wrote:
>
> Am 2021-01-08 02:24, schrieb Saravana Kannan:
> > The device link device's name was of the form:
> > --
> >
> > This can cause name collision as reported here [1] as device names are
> > not globally unique. Since device names have to be
On Thu, Jan 07, 2021 at 06:51:07PM -0800, Hyunwook (Wooky) Baek wrote:
> Don't assume dest/source buffers are userspace addresses when manually
> copying data for string I/O or MOVS MMIO, as {get,put}_user() will fail
> if handed a kernel address and ultimately lead to a kernel panic.
>
>
On 1/7/21 6:08 PM, 彭浩(Richard) wrote:
struct bpf_object *obj is not used in bpf_object__probe_loading, so we
can remove it.
Signed-off-by: Peng Hao
Acked-by: Yonghong Song
On CPUs with hardware AF/DBM, initialising prefaulted PTEs as 'old'
improves vmscan behaviour and does not appear to introduce any overhead.
Implement arch_wants_old_prefaulted_pte() to return 'true' if we detect
hardware access flag support at runtime. This can be extended in future
based on
From: "Kirill A. Shutemov"
alloc_set_pte() has two users with different requirements: in the
faultaround code, it called from an atomic context and PTE page table
has to be preallocated. finish_fault() can sleep and allocate page table
as needed.
PTL locking rules are also strange, hard to
Commit 5c0a85fad949 ("mm: make faultaround produce old ptes") changed
the "faultaround" behaviour to initialise prefaulted PTEs as 'old',
since this avoids vmscan wrongly assuming that they are hot, despite
having never been explicitly accessed by userspace. The change has been
shown to benefit
Hi all,
This is version two of the series I originally posted here:
https://lore.kernel.org/r/20201209163950.8494-1-w...@kernel.org
The patches allow architectures to opt-in at runtime for faultaround
mappings to be created as 'old' instead of 'young'. Although there have
been previous
On 1/8/2021 1:49 AM, Preeti Nagar wrote:
> The changes introduce a new security feature, RunTime Integrity Check
> (RTIC), designed to protect Linux Kernel at runtime. The motivation
> behind these changes is:
> 1. The system protection offered by SE for Android relies on the
> assumption of
On Tue, 5 Jan 2021 18:44:40 +0100, Krzysztof Kozlowski wrote:
> After converting to builtin driver, the probe function should not call
> __init functions anymore:
>
> >> WARNING: modpost: vmlinux.o(.text+0x8884d4):
> Section mismatch in reference from the function exynos_chipid_probe() to
The following commit has been merged into the ras/core branch of tip:
Commit-ID: 7bb39313cd6239e7eb95198950a02b4ad2a08316
Gitweb:
https://git.kernel.org/tip/7bb39313cd6239e7eb95198950a02b4ad2a08316
Author:Paul E. McKenney
AuthorDate:Wed, 23 Dec 2020 17:04:19 -08:00
Dell Customer Communication - Confidential
Perry,
For discussion in public mailing lists you'll have to make sure that you get
Dell's mail service to turn off this clause and resend:
>
> Dell Customer Communication - Confidential
>
Dell Customer Communication - Confidential
> -Original Message-
> From: Barnabás Pőcze
> Sent: 2021年1月8日 0:04
> To: Hans de Goede
> Cc: Yuan, Perry; mgr...@linux.intel.com; platform-driver-
> x...@vger.kernel.org; linux-kernel@vger.kernel.org; Limonciello, Mario
> Subject: Re: [PATCH v2
Hi Eric,
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 18 November 2020 11:22
> To: eric.auger@gmail.com; eric.au...@redhat.com;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu;
On 08/01/2021 16:51, Marc Zyngier wrote:
Hi Steven,
On 2021-01-08 16:12, Steven Price wrote:
KASAN in HW_TAGS mode will store MTE tags in the top byte of the
pointer. When computing the offset for TPIDR_EL2 we don't want anything
in the top byte, so remove the tag to ensure the computation is
On Fri, Jan 08, 2021 at 09:36:49AM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 07, 2021 at 04:45:33PM -0500, Andrea Arcangeli wrote:
> > On Thu, Jan 07, 2021 at 04:25:25PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Jan 07, 2021 at 03:04:00PM -0500, Andrea Arcangeli wrote:
> > >
> > > > vmsplice
On Fri, Jan 08, 2021 at 08:54:44AM +1100, Dave Chinner wrote:
> On Mon, Jan 04, 2021 at 11:23:53AM -0500, Brian Foster wrote:
> > On Thu, Dec 31, 2020 at 09:16:11AM +1100, Dave Chinner wrote:
> > > On Wed, Dec 30, 2020 at 12:56:27AM +0100, Donald Buczek wrote:
> > > > If the value goes below the
401 - 500 of 983 matches
Mail list logo
