Kernel allocator code accesses metadata for slab objects, that may lie
out-of-bounds of the object itself, or be accessed when an object is freed.
Such accesses trigger tag faults and lead to false-positive reports with
hardware tag-based KASAN.
Software KASAN modes disable instrumentation for
Hardware tag-based KASAN has granules of MTE_GRANULE_SIZE. Define
KASAN_GRANULE_SIZE to MTE_GRANULE_SIZE for CONFIG_KASAN_HW_TAGS.
Signed-off-by: Andrey Konovalov
Signed-off-by: Vincenzo Frascino
Reviewed-by: Marco Elver
---
Change-Id: I5d1117e6a991cbca00d2cfb4ba66e8ae2d8f513a
---
Provide implementation of KASAN functions required for the hardware
tag-based mode. Those include core functions for memory and pointer
tagging (tags_hw.c) and bug reporting (report_tags_hw.c). Also adapt
common KASAN code to support the new mode.
Signed-off-by: Andrey Konovalov
Signed-off-by:
With the intoduction of hardware tag-based KASAN some kernel checks of
this kind:
ifdef CONFIG_KASAN
will be updated to:
if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
x86 and s390 use a trick to #undef CONFIG_KASAN for some of the code
that isn't linked with KASAN
Hardware tag-based KASAN is now ready, enable the configuration option.
Signed-off-by: Andrey Konovalov
Signed-off-by: Vincenzo Frascino
Acked-by: Catalin Marinas
---
Change-Id: I6eb1eea770e6b61ad71c701231b8d815a7ccc853
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
On Wed, Sep 30, 2020 at 02:58:14PM -0700, Sean V Kelley wrote:
> From: Jonathan Cameron
>
> Currently the kernel does not handle AER errors for Root Complex
> integrated End Points (RCiEPs)[0]. These devices sit on a root bus within
> the Root Complex (RC). AER handling is performed by a Root
Hi,
On 10/1/20 11:40 PM, Doug Anderson wrote:
> Hi,
>
> On Wed, Sep 16, 2020 at 12:26 AM Stanimir Varbanov
> wrote:
>>
>> Hi,
>>
>> On 9/16/20 8:33 AM, Rajendra Nayak wrote:
>>>
>>> On 9/1/2020 7:50 PM, Rajendra Nayak wrote:
Rob, can you pick PATCH 1 since its already reviewed by you.
Hi Saravana,
Thank you for the patch.
On Thu, Oct 01, 2020 at 03:59:51PM -0700, Saravana Kannan wrote:
> When commit 93d2e4322aa7 ("of: platform: Batch fwnode parsing when
> adding all top level devices") optimized the fwnode parsing when all top
> level devices are added, it missed out
On Thu, Oct 01, 2020 at 02:06:10PM -0700, Sargun Dhillon wrote:
> On Wed, Sep 30, 2020 at 4:07 AM Michael Kerrisk (man-pages)
> wrote:
> >
> > Hi Tycho, Sargun (and all),
> >
> > I knew it would be a big ask, but below is kind of the manual page
> > I was hoping you might write [1] for the
On Wed, Sep 30, 2020 at 08:06:23PM -0700, Florian Fainelli wrote:
> The intent of 412a1526d067 ("net: dsa: untag the bridge pvid from rx
> skbs") is to transparently untag the bridge's default_pvid when the
> Ethernet switch can only support egress tagged of that default_pvid
> towards the CPU
Hi Thomas,
On 9/30/2020 11:32 AM, Thomas Gleixner wrote:
On Tue, Sep 15 2020 at 16:27, Dave Jiang wrote:
@@ -1303,9 +1303,10 @@ static void intel_irq_remapping_prepare_irte(struct
intel_ir_data *data,
case X86_IRQ_ALLOC_TYPE_HPET:
case X86_IRQ_ALLOC_TYPE_PCI_MSI:
case
On Wed, Sep 30, 2020 at 08:27:05PM -0400, Jonathan Marek wrote:
> This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
> which otherwise doesn't provide any method for cleaning/invalidating the
> cache to sync with the device.
>
> Signed-off-by: Jonathan Marek
> ---
>
On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
> Add kernel functions to fetch a pointer to a POSIX dynamic clock
> using a user file description dynamic clock ID.
And how is that supposed to work. What are the lifetime rules?
> +struct posix_clock *posix_clock_get_clock(clockid_t id)
> +{
> +
On Fri, Oct 02, 2020 at 02:24:02AM +0300, Vladimir Oltean wrote:
> The explanation is super confusing, although I think the placement of
> the "skb->vlan_proto = vlan_dev_vlan_proto(upper_dev)" is correct.
No, I think it _is_ wrong, after all, I think you're repairing
skb->vlan_proto only for
On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae wrote:
>
> Intel's Extended Feature Disable (XFD) feature is an extension of the XSAVE
> architecture. XFD allows the kernel to enable a feature state in XCR0 and
> to receive a #NM trap when a task uses instructions accessing that state.
> In this way,
On Thu, Oct 01, 2020 at 10:16:35PM +0200, Jann Horn wrote:
> > A subclass isn't right, it has to be a _nested annotation.
> >
> > nested locking is a pretty good reason to not be able to do this, this
> > is something lockdep does struggle to model.
>
> Did I get the terminology wrong? I thought
On Thu, Oct 1, 2020 at 1:42 PM Chang S. Bae wrote:
>
> task->fpu has a buffer to keep the extended register states, but it is not
> expandable at runtime. Introduce runtime methods and new fpu struct fields
> to support the expansion.
>
> fpu->state_mask indicates the saved states per task and
On Thu, Oct 01, 2020 at 12:40:02AM +0200, Rikard Falkeborn wrote:
> Constify a couple of static struct attribute_group that are never
> modified to allow the compiler to put them in read-only memory.
>
> Rikard Falkeborn (2):
> RDMA/core: Constify struct attribute_group
> RDMA/rtrs: Constify
On Wed, Sep 30, 2020 at 08:27:04PM -0400, Jonathan Marek wrote:
> Add a new cache mode for creating coherent host-cached BOs.
Reviewed-by: Jordan Crouse
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> drivers/gpu/drm/msm/msm_drv.h | 1 +
On 10/1/2020 4:24 PM, Vladimir Oltean wrote:
On Wed, Sep 30, 2020 at 08:06:23PM -0700, Florian Fainelli wrote:
The intent of 412a1526d067 ("net: dsa: untag the bridge pvid from rx
skbs") is to transparently untag the bridge's default_pvid when the
Ethernet switch can only support egress
On Thu, Oct 01, 2020 at 04:48:43PM -0700, Florian Fainelli wrote:
> > - move dsa_untag_bridge_pvid() after eth_type_trans(), similar to what
> >you did in your initial patch - maybe this is the cleanest
>
> This would be my preference and it would not be hurting the fast-path that
> much.
Ok,
Hi Stefan,
On Thu, Oct 01, 2020 at 11:07:00AM +0200, Stefan Riedmüller wrote:
> On 30.09.20 13:42, Laurent Pinchart wrote:
> > On Wed, Sep 30, 2020 at 12:51:29PM +0200, Stefan Riedmueller wrote:
> >> From: Christian Hemp
> >>
> >> Aside from 12 bit monochrome or color format the sensor
On Fri, Oct 2, 2020 at 1:41 AM Jason Gunthorpe wrote:
> On Thu, Oct 01, 2020 at 10:16:35PM +0200, Jann Horn wrote:
> > > A subclass isn't right, it has to be a _nested annotation.
> > >
> > > nested locking is a pretty good reason to not be able to do this, this
> > > is something lockdep does
Hi Stefan,
Thank you for the patch.
On Wed, Sep 30, 2020 at 12:51:30PM +0200, Stefan Riedmueller wrote:
> From: Enrico Scholz
>
> The real and requested clock can differ and because it is used to
> calculate PLL values, the real clock rate should be read.
>
> Signed-off-by: Enrico Scholz
>
Hi Stefan,
On Thu, Oct 01, 2020 at 10:56:24AM +0200, Stefan Riedmüller wrote:
> On 30.09.20 13:38, Laurent Pinchart wrote:
> > On Wed, Sep 30, 2020 at 12:51:31PM +0200, Stefan Riedmueller wrote:
> >> From: Enrico Scholz
> >>
> >> Implement g_register and s_register v4l2_subdev_core_ops to access
Hi Stefan,
Thank you for the patch.
On Wed, Sep 30, 2020 at 12:51:33PM +0200, Stefan Riedmueller wrote:
> From: Dirk Bender
>
> To prevent corrupted frames after starting and stopping the sensor it's
s/it's/its/
> datasheet specifies a specific pause sequence to follow:
>
> Stopping:
>
On Thu, 1 Oct 2020, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/mptcp/protocol.c
between commit:
917944da3bfc ("mptcp: Consistently use READ_ONCE/WRITE_ONCE with msk->ack_seq")
from the net tree and commit:
8268ed4c9d19
Hi Roman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
url:
https://github.com/0day-ci/linux/commits/Roman-Gushchin/mm-memcg-slab-fix-slab-statistics-in-SMP-configuration/20201002-044114
base: git://git.cmpxchg.org/linux-mmotm.git master
On Thu, Oct 1, 2020 at 9:00 AM Kalesh Singh wrote:
>
> On Thu, Oct 1, 2020 at 8:27 AM Kirill A. Shutemov
> wrote:
> >
> > On Wed, Sep 30, 2020 at 03:42:17PM -0700, Lokesh Gidra wrote:
> > > On Wed, Sep 30, 2020 at 3:32 PM Kirill A. Shutemov
> > > wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at
On Thu, 1 Oct 2020, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/mptcp/protocol.h
between commit:
1a49b2c2a501 ("mptcp: Handle incoming 32-bit DATA_FIN values")
from the net tree and commit:
5c8c1640956e ("mptcp: add
On Fri, Oct 02 2020 at 00:05, Thomas Gleixner wrote:
> On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
>
> same comments as for patch 1 apply.
>
>> Add kernel function to retrieve main clock oscillator state.
>
> The function you are adding is named adjtimex(). adjtimex(2) is a well
> known user
The Broadcast Assist Unit (BAU) TLB shootdown handler is being rewritten
to become the UV BAU APIC driver. It is designed to speed up sending
IPI's to selective CPUs within the system. Remove the current TLB
shutdown handler (tlb_uv.c) file and a couple of kernel hooks in the
interim.
Add new references to UV5 (and UVY class) system MMR addresses and
fields primarily caused by the expansion from 46 to 52 bits of
physical memory address.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h | 49
UV class systems no longer use System Controller for monitoring of CPU
activity provided by this driver. Other methods have been developed
for BIOS and the management controller (BMC). This patch removes that
supporting code.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
---
Add Copyrights to those files that have been updated for UV5 changes.
Signed-off-by: Mike Travis
---
arch/x86/include/asm/uv/bios.h | 1 +
arch/x86/include/asm/uv/uv_hub.h| 1 +
arch/x86/include/asm/uv/uv_mmrs.h | 1 +
arch/x86/kernel/apic/x2apic_uv_x.c | 1 +
Make modifications to the GAM MMR mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git
The changes in the UV5 arch shrunk the NODE PRESENT table to just 2x64
entries (128 total) so are in to 64 bit MMRs instead of a depth of 64
bits in an array. Adjust references when counting up the nodes present.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
Make modifications to the GRU mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git
-a015-20200930
x86_64 randconfig-a013-20200930
x86_64 randconfig-a012-20200930
x86_64 randconfig-a016-20200930
x86_64 randconfig-a014-20200930
x86_64 randconfig-a011-20200930
x86_64 randconfig-a012-20201001
x86_64
Changes included in this patch set:
* Add changes needed for new UV5 UV architecture. Chief among the
changes are 52 bits of physical memory address and 57 bits of
virtual address space.
* Remove the BAU TLB code cuurently being replaced by BAU APIC driver.
* Remove System
Make modifications to the MMIOH mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 211 +++--
1 file changed, 143 insertions(+), 68 deletions(-)
diff --git
On Sun, Sep 13, 2020 at 01:29:28PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> The various array_size functions use SIZE_MAX define, but missed limits.h
> causes to failure to compile code that needs overflow.h.
>
> In file included from
On Wed, Sep 23, 2020 at 07:50:11PM +0300, Leon Romanovsky wrote:
> When an application is not using RDMA CM and if it is using multiple RDMA
> devices with one or more RoCE ports, finding the right GID table entry is
> a long process.
>
> For example, with two RoCE dual-port devices in a system,
On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
> - Add support for using a POSIX dynamic clock with
> Traffic control Earliest TxTime First (ETF) Qdisc.
> --- a/include/uapi/linux/net_tstamp.h
> +++ b/include/uapi/linux/net_tstamp.h
> @@ -167,6 +167,11 @@ enum txtime_flags {
>
Make a small symbol change (is_uv() ==> is_uv_sys()) to accommodate a
change in the uv_mmrs.h file (is_uv() is the new arch selector function).
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
drivers/misc/sgi-xp/xp.h| 8
The UV NMI MMR addresses and fields moved between UV4 and UV5
necessitating a rewrite of the UV NMI handler. Adjust references
to accommodate those changes.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h | 13 ---
Update check of BIOS TSC sync status to include both possible "invalid"
states provided by newer UV5 BIOS.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h | 2 +-
arch/x86/kernel/apic/x2apic_uv_x.c | 24 ++--
2 files changed, 11
On 10/1/20 11:51 AM, Stephen Boyd wrote:
> Quoting Mark Brown (2020-10-01 10:43:26)
>> On Wed, Sep 30, 2020 at 05:07:20PM -0700, Stephen Boyd wrote:
>>> Quoting David Collins (2020-09-22 15:04:18)
>>
This helps to disambiguate SPMI device regmaps from I2C ones
at /sys/kernel/debug/regmap
On Thu, Oct 01, 2020 at 01:10:05PM -0700, David Miller wrote:
> From: Vladimir Oltean
> Date: Thu, 1 Oct 2020 16:20:11 +0300
>
> > Seville is a DSA switch that is embedded inside the T1040 SoC, and
> > supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
> >
> > This series
A patch to add and process the UV Arch Type field in the UVsystab passed
from UV BIOS to the kernel. This allows the system to be recognized
without relying on the OEM_ID which OEMs want to change.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
On Fri, Oct 02, 2020 at 08:08:40AM +0800, kbuild test robot wrote:
> Hi Roman,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on mmotm/master]
It's a bogus error, the patch was applied onto mmotm/master, which doesn't
contain necessary slab controller patches.
Die letzten Monate waren nicht gut für Unternehmen, Institutionen und
Einzelpersonen auf der ganzen Welt. Die globale Epidemie (Covid-19) hat alle
finanziell erschöpft und Sie wurden nicht freigestellt. Ihr Hilferuf wurde
gehört und wir sind bereit, Ihnen unsere freundliche Geste anzubieten.
Hi,
I reported in the v13 cover letter of kvm dirty ring series that this patch
seems to have been broken. Today I tried to reproduce with a simplest vm, and
after a closer look...
On Fri, Sep 25, 2020 at 04:34:20PM +0200, Alexander Graf wrote:
> @@ -3764,15 +3859,14 @@ static u8
On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> >>> If we can't come to an agreement on globalizing mc pointer, would
> >>> it be possible to pass tegra_mc_driver through tegra_smmu_probe()
> >>> so we can continue to use driver_find_device_by_fwnode() as v1?
> >>>
> >>> v1:
:
BUG: kernel NULL pointer dereference, address: 0048
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0 P4D 0
Oops: [#1] PREEMPT SMP PTI
CPU: 4 PID: 158 Comm: kworker/4:2 Not tainted 5.9.0-rc7-test-next-20201001+ #12
Hardware name: H
On Thu, Oct 01, 2020 at 02:54:12PM -0700, Matthias Kaehlcke wrote:
> Hi,
>
> thanks for providing more insights on the USB hardware!
Sure.
> On Wed, Sep 30, 2020 at 09:24:13PM -0400, Alan Stern wrote:
> > A hub that attaches only to the USB-3 data wires in a cable is not USB
> > compliant. A
These two patches replace "mmap locking API: don't check locking
if the mm isn't live yet"[1], which is currently in the mmotm tree,
and should be placed in the same spot where the old patch was.
While I originally said that this would be an alternative
patch (meaning that the existing patch
Today I decided to implement VM_HUGEPAGE support for XFS. It turned out
to be a rather simpler implementation than I was expecting because I
could reuse the readahead implementation.
Feel free to try it for yourself:
http://git.infradead.org/users/willy/pagecache.git
The patches up to "fs: Do
Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
of the old mm (in dup_mmap() and in UML's activate_mm()).
A following patch will change the exec path to very broadly lock the
nascent mm, but fine-grained locking should still work at the same time for
the new mm.
To do
While AFAIK there currently is nothing that can modify the VMA tree of a
new mm until userspace has started running under the mm, we should properly
lock the mm here anyway, both to keep lockdep happy when adding locking
assertions and to be safe in the future in case someone e.g. decides to
On 9/30/20 11:01 PM, Leon Romanovsky wrote:
> On Tue, Sep 29, 2020 at 12:13:56PM +0300, Leon Romanovsky wrote:
>> From: Leon Romanovsky
>>
>> There are no drivers that implement .get_vector_affinity(), so delete
>> the RDMA function and simplify block code.
>>
>> Thanks
>>
>> P.S. Probably it
0x) - not-present page
PGD 0 P4D 0
Oops: [#1] PREEMPT SMP PTI
CPU: 4 PID: 158 Comm: kworker/4:2 Not tainted 5.9.0-rc7-test-next-20201001+ #12
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03
07/14/2016
Workqueue: 0x0 (events)
RIP
On 2020/10/2 02:47, Vicente Bergas wrote:
> On Thursday, October 1, 2020 9:18:24 AM CEST, Coly Li wrote:
>> In mmc_queue_setup_discard() the mmc driver queue's discard_granularity
>> might be set as 0 (when card->pref_erase > max_discard) while the mmc
>> device still declares to support discard
On Thu, Oct 01, 2020 at 12:46:14PM +0200, Thierry Reding wrote:
> > > > - /*
> > > > -* This is a bit of a hack. Ideally we'd want to simply return
> > > > this
> > > > -* value. However the IOMMU registration process will attempt
> > > > to add
> > > > -* all
From: Xie He
Date: Mon, 28 Sep 2020 05:56:43 -0700
> The fr_hard_header function is used to prepend the header to skbs before
> transmission. It is used in 3 situations:
> 1) When a control packet is generated internally in this driver;
> 2) When a user sends an skb on an Ethernet-emulating PVC
In mmc_queue_setup_discard() the mmc driver queue's discard_granularity
might be set as 0 (when card->pref_erase > max_discard) while the mmc
device still declares to support discard operation. This is buggy and
triggered the following kernel warning message,
WARNING: CPU: 0 PID: 135 at
From: Stephen Rothwell
Date: Tue, 29 Sep 2020 13:04:46 +1000
> Caused by commit
>
> eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested
> interface infrastructure")
>
> interacting with commit
>
> e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver
From: Jing Xiangfeng
Date: Wed, 30 Sep 2020 09:29:54 +0800
> After commit a8c7687bf216 ("caif_virtio: Check that vringh_config is not
> null"), the variable err is being initialized with '-EINVAL' that is
> meaningless. So remove it.
>
> Signed-off-by: Jing Xiangfeng
Applied to net-next.
From: Willy Liu
Date: Wed, 30 Sep 2020 14:48:58 +0800
> Realtek single-chip Ethernet PHY solutions can be separated as below:
> 10M/100Mbps: RTL8201X
> 1Gbps: RTL8211X
> 2.5Gbps: RTL8226/RTL8221X
> RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY.
> Since RTL8226 is
Hi Sameer
> As per the members exposed earlier in the series, audio graph driver
> is updated to make use of these. Functionally there is no change
> in behavior if these are not populated. So following changes are made
> as part of this.
>
> - Update 'dai_link->ops' for DPCM links if a
Hi Sameer
Thank you for the patch
> Add new members in struct 'asoc_simple_priv'. Idea is to leverage
> simple or graph card driver as much as possible and vendor can
> maintain a thin driver to control the behavior by populating these
> newly exposed members.
re-use simple/audio-graph driver
02.10.2020 04:07, Nicolin Chen пишет:
> On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> If we can't come to an agreement on globalizing mc pointer, would
> it be possible to pass tegra_mc_driver through tegra_smmu_probe()
> so we can continue to use
Hi Dave,
On Thu, 01 Oct 2020 18:40:13 -0700 (PDT) David Miller
wrote:
>
> From: Stephen Rothwell
> Date: Tue, 29 Sep 2020 13:04:46 +1000
>
> > Caused by commit
> >
> > eff7423365a6 ("net: core: introduce struct netdev_nested_priv for nested
> > interface infrastructure")
> >
> >
Hi Michal,
Thank you for the patch.
On Tue, Sep 29, 2020 at 01:43:22PM +0200, Michal Simek wrote:
> DT schema is checking tuples which should be properly separated. The patch
> is doing this separation to avoid the following warning:
> ..yaml: axi: pcie@fd0e:ranges: [[33554432, 0,
On Fri, Sep 25, 2020 at 7:57 AM Yu-cheng Yu wrote:
>
> There was no more caller passing vm_flags to do_mmap(), and vm_flags was
> removed from the function's input by:
>
> commit 45e55300f114 ("mm: remove unnecessary wrapper function
> do_mmap_pgoff()").
>
> There is a new user now. Shadow
Hi--
On 10/1/20 1:39 PM, Chang S. Bae wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index a1068742a6df..742167c6f789 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++
From: Anant Thazhemadam
Date: Thu, 1 Oct 2020 13:02:20 +0530
> When get_registers() fails (which happens when usb_control_msg() fails)
> in set_ethernet_addr(), the uninitialized value of node_id gets copied
> as the address.
>
> Checking for the return values appropriately, and handling the
From: Corey Minyard
If you write to a pty master an immediately close the pty master, the
receiver might get a chunk of data dropped, but then receive some later
data. That's obviously something rather unexpected for a user. It
certainly confused my test program.
It turns out that
On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Get straight to the point in a few paragraphs instead of forcing users
> to read quite a bit of text, like the old approach did.
>
> All normally needed fits into the first two paragraphs. The third is
> dedicated to issues only happening in stable
Hi, Alexander
在 2020年09月30日 18:23, Alexander Egorenkov 写道:
> The offset of the field 'init_uts_ns.name' has changed
> since commit 9a56493f6942 ("uts: Use generic ns_common::count").
>
> Link:
> https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain
>
>
When a DSA switch driver needs to call dsa_untag_bridge_pvid(), it can
set dsa_switch::untag_brige_pvid to indicate this is necessary.
This is a pre-requisite to making sure that we are always calling
dsa_untag_bridge_pvid() after eth_type_trans() has been called.
Signed-off-by: Florian Fainelli
Now that dsa_untag_bridge_pvid() is called after eth_type_trans() we are
guaranteed that skb->protocol will be set to a correct value, thus
allowing us to avoid calling vlan_eth_hdr().
Signed-off-by: Florian Fainelli
---
net/dsa/dsa_priv.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Hi David, Jakub,
This patch series is based on the recent discussions with Vladimir:
https://lore.kernel.org/netdev/20201001030623.343535-1-f.faine...@gmail.com/
the simplest way forward was to call dsa_untag_bridge_pvid() after
eth_type_trans() has been set which guarantees that skb->protocol
Indicate to the DSA receive path that we need to untage the bridge PVID,
this allows us to remove the dsa_untag_bridge_pvid() calls from
net/dsa/tag_brcm.c.
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/b53/b53_common.c | 1 +
net/dsa/tag_brcm.c | 15 ++-
2
Now that we are guaranteed that dsa_untag_bridge_pvid() is called after
eth_type_trans() we can utilize __vlan_find_dev_deep_rcu() which will
take care of finding an 802.1Q upper on top of a bridge master.
A common use case, prior to 12a1526d067 ("net: dsa: untag the bridge
pvid from rx skbs")
Currently, init_listener() tries to prevent adding a filter with
SECCOMP_FILTER_FLAG_NEW_LISTENER if one of the existing filters already
has a listener. However, this check happens without holding any lock that
would prevent another thread from concurrently installing a new filter
(potentially
ago
config: x86_64-randconfig-a003-20201001 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
bcd05599d0e53977a963799d6ee4f6e0bc21331b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
On Fri, Oct 02, 2020 at 04:55:34AM +0300, Dmitry Osipenko wrote:
> 02.10.2020 04:07, Nicolin Chen пишет:
> > On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote:
> > If we can't come to an agreement on globalizing mc pointer, would
> > it be possible to pass tegra_mc_driver
On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
>
> Signed-off-by: Thorsten Leemhuis
> ---
> Documentation/admin-guide/reporting-bugs.rst | 103 +++
> 1 file changed, 103 insertions(+)
>
> diff --git a/Documentation/admin-guide/reporting-bugs.rst
>
> -Original Message-
> From: Andi Kleen [mailto:a...@linux.intel.com]
> Sent: Friday, October 2, 2020 12:07 PM
> To: Song Bao Hua (Barry Song)
> Cc: linux-kernel@vger.kernel.org; Linuxarm ; Peter
> Zijlstra ; Ingo Molnar ; Arnaldo
> Carvalho de Melo ; Mark Rutland
> ; Alexander
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
Documentation/devicetree/bindings/net/renesas,ravb.txt
between commit:
307eea32b202 ("dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC")
from the net tree and commit:
d7adf6331189 ("dt-bindings: net:
On Thu, Sep 24, 2020 at 08:31:02PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 24, 2020 at 07:09:08PM -0700, Eric Biggers wrote:
> > On Thu, Sep 24, 2020 at 05:59:34PM -0700, Paul E. McKenney wrote:
> > > On Tue, Sep 22, 2020 at 02:55:58PM -0700, Eric Biggers wrote:
> > > > On Tue, Sep 22, 2020
On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Handle stable and longterm kernels in a subsection, as dealing with them
> directly in the main part of the step-by-step guide turned out to make
> it messy and hard to follow: it looked a bit like code with a large
> amount of if-then-else section to
-20201001
x86_64 randconfig-a015-20201001
x86_64 randconfig-a014-20201001
x86_64 randconfig-a013-20201001
x86_64 randconfig-a011-20201001
x86_64 randconfig-a016-20201001
i386 randconfig-a011-20200930
i386
randconfig-a013-20200930
x86_64 randconfig-a012-20200930
x86_64 randconfig-a016-20200930
x86_64 randconfig-a014-20200930
x86_64 randconfig-a011-20200930
x86_64 randconfig-a012-20201001
x86_64 randconfig-a015-20201001
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
between commit:
b19515253623 ("drm/amd/pm: setup APU dpm clock table in SMU HW
initialization")
from the Linus tree and commits:
82cac71c1b64 ("drm/amd/pm: put Navi1X umc cdr
Hi all,
On Wed, 30 Sep 2020 14:07:15 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> tools/lib/bpf/btf.c
>
> between commit:
>
> 1245008122d7 ("libbpf: Fix native endian assumption when parsing BTF")
>
> from the bpf tree and
Clang warns:
drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: missing braces around
initializer [-Wmissing-braces]
union ufs_crypto_cfg_entry cfg = { 0 };
^
Signed-off-by: Pujin Shi
---
drivers/scsi/ufs/ufshcd-crypto.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Clang warns:
drivers/scsi/ufs/ufshcd-crypto.c:103:8: warning: missing braces around
initializer [-Wmissing-braces]
union ufs_crypto_cfg_entry cfg = { 0 };
^
Signed-off-by: Pujin Shi
---
drivers/scsi/ufs/ufshcd-crypto.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 10/1/20 3:22 PM, Andreas Kemnade wrote:
> On Wed, 30 Sep 2020 22:00:09 +0200
> Arnd Bergmann wrote:
>
>> On Wed, Sep 30, 2020 at 6:44 PM Guenter Roeck wrote:
>>>
>>> On Wed, Sep 30, 2020 at 10:54:42AM +0200, Andreas Kemnade wrote:
Hi,
after the $subject patch I get lots of
1 - 100 of 1339 matches
Mail list logo
