Re: kernel BUG at lib/lockref.c:LINE!
On Mon, Jul 08, 2019 at 12:37:06PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:d58b5ab9 Add linux-next specific files for 20190708
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=123d6887a0
> kernel config: https://syzkaller.appspot.com/x/.config?x=bf9882946ecc11d9
> dashboard link: https://syzkaller.appspot.com/bug?extid=f70e9b00f8c7d4187bd0
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=173375c7a0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1536f9bfa0
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+f70e9b00f8c7d4187...@syzkaller.appspotmail.com
>
> [ cut here ]
> kernel BUG at lib/lockref.c:189!
Mea culpa... It's "Teach shrink_dcache_parent() to cope with mixed-filesystem
shrink lists", and the fix should be simply this:
diff --git a/fs/dcache.c b/fs/dcache.c
index d8732cf2e302..d85d8f2c8c97 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1555,6 +1555,7 @@ void shrink_dcache_parent(struct dentry *parent)
d_walk(parent, , select_collect2);
if (data.victim) {
struct dentry *parent;
+ spin_lock(>d_lock);
if (!shrink_lock_dentry(data.victim)) {
rcu_read_unlock();
} else {
Re: m68k build failures in -next: undefined reference to `arch_dma_prep_coherent'
On Mon, Jul 08, 2019 at 10:19:41PM +0200, Geert Uytterhoeven wrote: > Yeah, it started when I queued up the DMA rework. > I didn't double-check when Greg said it was OK for him, as it wouldn't affect > Coldfire or mmu. Sorry for that. > And that has just been pulled by Linus... Oops... The fix should have been in your inbox for a while..
Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
On Mon, Jul 08, 2019 at 09:26:29PM +0200, Jiri Pirko wrote: > Mon, Jul 08, 2019 at 07:27:29PM CEST, mkube...@suse.cz wrote: > > > >There are two reasons for this design. First is to reduce the number of > >requests needed to get the information. This is not so much a problem of > >ethtool itself; the only existing commands that would result in multiple > >request messages would be "ethtool " and "ethtool -s ". Maybe > >also "ethtool -x/-X " but even if the indirection table and hash > >key have different bits assigned now, they don't have to be split even > >if we split other commands. It may be bigger problem for daemons wanting > >to keep track of system configuration which would have to issue many > >requests whenever a new device appears. > > > >Second reason is that with 8-bit genetlink command/message id, the space > >is not as infinite as it might seem. I counted quickly, right now the > >full series uses 14 ids for kernel messages, with split you propose it > >would most likely grow to 44. For full implementation of all ethtool > >functionality, we could get to ~60 ids. It's still only 1/4 of the > >available space but it's not clear what the future development will look > >like. We would certainly need to be careful not to start allocating new > >commands for single parameters and try to be foreseeing about what can > >be grouped together. But we will need to do that in any case. > > > >On kernel side, splitting existing messages would make some things a bit > >easier. It would also reduce the number of scenarios where only part of > >requested information is available or only part of a SET request fails. > > Okay, I got your point. So why don't we look at if from the other angle. > Why don't we have only single get/set command that would be in general > used to get/set ALL info from/to the kernel. Where we can have these > bits (perhaps rather varlen bitfield) to for user to indicate which data > is he interested in? This scales. The other commands would be > just for action. > > Something like RTM_GETLINK/RTM_SETLINK. Makes sense? It's certainly an option but at the first glance it seems as just moving what I tried to avoid one level lower. It would work around the u8 issue (but as Johannes pointed out, we can handle it with genetlink when/if the time comes). We would almost certainly have to split the replies into multiple messages to keep the packet size reasonable. I'll have to think more about the consequences for both kernel and userspace. My gut feeling is that out of the two extreme options (one universal message type and message types corresponding to current infomask bits), the latter is more appealing. After all, ethtool has been gathering features that would need those ~60 message types for 20 years. Michal
Re: [PATCH 3.16 000/129] 3.16.70-rc1 review
On Mon, Jul 08, 2019 at 04:29:22PM +0100, Ben Hutchings wrote: > On Mon, 2019-07-08 at 06:05 -0700, Luke Nowakowski-Krijger wrote: > > Hello, > > > > I got 1 error when applying this patch series to the latest linux-3.16.y > > stable branch > > > > fs/fuse/file.c:218:3: error: implicit declaration of function ‘stream_open’ > > It is added by the previous patch and declared in . > fs/fuse/file.c always includes that (via fs/fuse/fuse_i.h), so I don't > see how this error can happen. > > Ben. > I was actually in another src tree. My mistake. Rebuilding it off of your tree, I get no compilation errors and it boots on my x86_64 machine. > -- > Ben Hutchings > Time is nature's way of making sure that > everything doesn't happen at once. > > Also this is a good thing to remember. Thanks, - Luke
Re: [PATCH v5 4/5] mm/slab: Refactor common ksize KASAN logic into slab_common.c
On Mon, 8 Jul 2019, Marco Elver wrote: > This refactors common code of ksize() between the various allocators > into slab_common.c: __ksize() is the allocator-specific implementation > without instrumentation, whereas ksize() includes the required KASAN > logic. Acked-by: Christoph Lameter
Re: m68k build failures in -next: undefined reference to `arch_dma_prep_coherent'
Hi Günter,
CC Greg
On Mon, Jul 8, 2019 at 9:45 PM Guenter Roeck wrote:
> On Mon, Jul 08, 2019 at 09:13:02PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jul 8, 2019 at 7:06 PM Guenter Roeck wrote:
> > > I see the following build error in -next:
> > >
> > > kernel/dma/direct.o: In function `dma_direct_alloc_pages':
> > > direct.c:(.text+0x4d8): undefined reference to `arch_dma_prep_coherent'
> > >
> > > Example: m68k:allnoconfig.
> > >
> > > Bisect log is ambiguous and points to the merge of m68k/for-next into
> > > -next. Yet, I think the problem is with commit 69878ef47562 ("m68k:
> > > Implement arch_dma_prep_coherent()") which is supposed to introduce
> > > the function. The problem is likely that arch_dma_prep_coherent()
> > > is only declared if CONFIG_MMU is enabled, but it is called from code
> > > outside CONFIG_MMU.
> >
> > Thanks, one more thing to fix in m68k-allnoconfig (did it really build
> > before?)...
> >
> > Given you say "example", does it fail in real configs, too?
>
> Yes, it does. All nommu builds fail. allnoconfig and tinyconfig just
> happen to be among those.
>
> Building m68k:allnoconfig ... failed
> Building m68k:tinyconfig ... failed
> Building m68k:m5272c3_defconfig ... failed
> Building m68k:m5307c3_defconfig ... failed
> Building m68k:m5249evb_defconfig ... failed
> Building m68k:m5407c3_defconfig ... failed
> Building m68k:m5475evb_defconfig ... failed
>
> Error is always the same.
Thanks!
> The error started with next-20190702. Prior to that, builds were fine,
> including m68k:allnoconfig and m68k:tinyconfig.
Yeah, it started when I queued up the DMA rework.
I didn't double-check when Greg said it was OK for him, as it wouldn't affect
Coldfire or mmu. Sorry for that.
And that has just been pulled by Linus... Oops...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3] RDMA/core: Fix race when resolving IP address
Den 08.07.2019 21:38, skrev Jason Gunthorpe: On Mon, Jul 08, 2019 at 07:22:45PM +, Mark Bloch wrote: On 7/8/19 11:47 AM, Dag Moxnes wrote: Thanks Jason, Regards, Dag Den 08.07.2019 19:50, skrev Jason Gunthorpe: On Mon, Jul 08, 2019 at 01:16:24PM +0200, Dag Moxnes wrote: Use neighbour lock when copying MAC address from neighbour data struct in dst_fetch_ha. When not using the lock, it is possible for the function to race with neigh_update, causing it to copy an invalid MAC address. It is possible to provoke this error by calling rdma_resolve_addr in a tight loop, while deleting the corresponding ARP entry in another tight loop. This will cause the race shown it the following sample trace: rdma_resolve_addr() rdma_resolve_ip() addr_resolve() addr_resolve_neigh() fetch_ha() dst_fetch_ha() n->nud_state == NUD_VALID It isn't nud_state that is the problem here, it is the parallel memcpy's onto ha. I fixed the commit message This could also have been solved by using the ha_lock, but I don't think we have a reason to particularly over-optimize this. Sorry I'm late to the party, but why not just use: neigh_ha_snapshot()? Yes, that is much better, please respin this OK, will do! Can I still post it as a v4? Or should I do it differently as you already applied it? Regards, -Dag Thanks, Jason
memory leaks from xfs_rw_bdev()
Booting today's linux-next starts to have several memory leaks. Looks like the new xfs_rw_bdev() was introduced in the commit "xfs: use bios directly to read and write the log recovery buffers". https://patchwork.kernel.org/patch/10977673/ unreferenced object 0x888f595487c0 (size 184): comm "mount", pid 1473, jiffies 4294946340 (age 14914.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 40 28 67 8f 88 ff ff .@(g 00 18 00 00 40 c6 00 00 00 00 00 00 00 00 00 00 @... backtrace: [<31fb6250>] kmem_cache_alloc+0x272/0x400 [<8ce62f00>] mempool_alloc_slab+0x2d/0x40 [<4eaa8110>] mempool_alloc+0x10a/0x29e [<906127bf>] bio_alloc_bioset+0x150/0x330 [<5d5cc981>] xfs_rw_bdev+0x72/0x300 [xfs] [] xlog_do_io+0xd8/0x1a0 [xfs] [<3815ee16>] xlog_bread+0x28/0x70 [xfs] [<883dc328>] xlog_find_verify_cycle+0x180/0x2c0 [xfs] [<457d45f8>] xlog_find_head+0x27c/0x5a0 [xfs] [<9956dd1f>] xlog_find_tail+0xdb/0x530 [xfs] [ ] xlog_recover+0x8f/0x2a0 [xfs] [ ] xfs_log_mount+0x247/0x3b0 [xfs] [ ] xfs_mountfs+0x7bd/0xe30 [xfs] [<128f1a43>] xfs_fs_fill_super+0x6f0/0xaa0 [xfs] [<0ead1e3b>] mount_bdev+0x1d9/0x220 [ ] xfs_fs_mount+0x15/0x20 [xfs]
Re: [PATCH] of/platform: Drop superfluous cast in of_device_make_bus_id()
On Mon, 24 Jun 2019 14:46:20 +0200, Geert Uytterhoeven wrote: > There is no need to cast "u64" to "unsigned long long" before printing > it, as both types have been made identical on all architectures many > years ago. > > Signed-off-by: Geert Uytterhoeven > --- > drivers/of/platform.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Applied, thanks. Rob
Re: [PATCH v3 6/7] dt-bindings: net: realtek: Add property to configure LED mode
Hi Andrew, On Mon, Jul 08, 2019 at 09:48:34PM +0200, Andrew Lunn wrote: > On Mon, Jul 08, 2019 at 12:24:58PM -0700, Matthias Kaehlcke wrote: > > The LED behavior of some Realtek PHYs is configurable. Add the > > property 'realtek,led-modes' to specify the configuration of the > > LEDs. > > > > Signed-off-by: Matthias Kaehlcke > > Hi Matthias > > Humm. I thought you were going to drop this and the next patch? It wasn't clear to me whether not introducing a generic interface is a definitive NACK and tought I could at least post a version with the review comments addressed. If there is no way forward without a generic interface I'll drop the two patches.
Re: [PATCH v3 1/7] dt-bindings: net: Add bindings for Realtek PHYs
On Mon, Jul 08, 2019 at 09:46:15PM +0200, Andrew Lunn wrote: > On Mon, Jul 08, 2019 at 12:24:53PM -0700, Matthias Kaehlcke wrote: > > Add the 'realtek,eee-led-mode-disable' property to disable EEE > > LED mode on Realtek PHYs that support it. > > > > Signed-off-by: Matthias Kaehlcke > > --- > > TODO: adapt PHY core to deal with optional compatible strings > > Yes. Does this even work at the moment? I would expect > of_mdiobus_child_is_phy() to return false, indicating the device is > not actually a PHY. Indeed, it currently doesn't work atm. I found that removing the check for dev->of_node in of_mdiobus_link_mdiodev() helps, but I imagine doing (only) this might have undesired side-effects.
[PATCH] mmc: dw_mmc: Fix occasional hang after tuning on eMMC
In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after
response errors.") we fixed a tuning-induced hang that I saw when
stress testing tuning on certain SD cards. I won't re-hash that whole
commit, but the summary is that as a normal part of tuning you need to
deal with transfer errors and there were cases where these transfer
errors was putting my system into a bad state causing all future
transfers to fail. That commit fixed handling of the transfer errors
for me.
In downstream Chrome OS my fix landed and had the same behavior for
all SD/MMC commands. However, it looks like when the commit landed
upstream we limited it to only SD tuning commands. Presumably this
was to try to get around problems that Alim Akhtar reported on exynos
[1].
Unfortunately while stress testing reboots (and suspend/resume) on
some rk3288-based Chromebooks I found the same problem on the eMMC on
some of my Chromebooks (the ones with Hynix eMMC). Since the eMMC
tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
same situation.
I'm hoping that whatever problems exynos was having in the past are
somehow magically fixed now and we can make the behavior the same for
all commands.
[1]
https://lkml.kernel.org/r/cagoxz53wfnbame0_am0qbqu47kafgmpbvzc8k8y-_j3mdmq...@mail.gmail.com
Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response
errors.")
Signed-off-by: Douglas Anderson
Cc: Marek Szyprowski
Cc: Alim Akhtar
Cc: Enric Balletbo i Serra
---
Marek (or anyone else using exynos): is it easy for you to test this
and check if things are still broken when we land this patch? If so,
I guess we could have a quirk to have different behavior for just
Rockchip SoCs but I'd rather avoid that if possible.
NOTE: I'm not hoping totally in vain here. It is possible that some
of the CTO/DTO timers that landed could be the magic that would get
exynos unstuck.
drivers/mmc/host/dw_mmc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b53b6b7d4dd4..60c3a06e3469 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2034,8 +2034,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
* delayed. Allowing the transfer to take place
* avoids races and keeps things simple.
*/
- if ((err != -ETIMEDOUT) &&
- (cmd->opcode == MMC_SEND_TUNING_BLOCK)) {
+ if (err != -ETIMEDOUT) {
state = STATE_SENDING_DATA;
continue;
}
--
2.22.0.410.gd8fdbe21b5-goog
Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
On 2019-07-05 18:37:35, Roberto Sassu wrote:
> Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a
> TPM") allows the trusted module to be loaded even a TPM is not found to
> avoid module dependency problems.
>
> Unfortunately, this does not completely solve the issue, as there could be
> a case where a TPM is found but is not functional (the TPM commands return
> an error). Specifically, after the tpm_chip structure is returned by
> tpm_default_chip() in init_trusted(), the execution terminates after
> init_digests() returns -EFAULT (due to the fact that tpm_get_random()
> returns a positive value, but less than TPM_MAX_DIGEST_SIZE).
>
> This patch fixes the issue by ignoring the TPM_ERR_DEACTIVATED and
> TPM_ERR_DISABLED errors.
>
> Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
> Signed-off-by: Roberto Sassu
> ---
> drivers/char/tpm/tpm.h | 2 --
> include/linux/tpm.h | 3 +++
> security/keys/trusted.c | 6 +-
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index e503ffc3aa39..a216ac396711 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -54,8 +54,6 @@ enum tpm_addr {
>
> #define TPM_WARN_RETRY 0x800
> #define TPM_WARN_DOING_SELFTEST 0x802
> -#define TPM_ERR_DEACTIVATED 0x6
> -#define TPM_ERR_DISABLED0x7
> #define TPM_ERR_INVALID_POSTINIT 38
>
> #define TPM_HEADER_SIZE 10
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 53c0ea9ec9df..efd3ccbb6aee 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -26,6 +26,9 @@
> #define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
> #define TPM_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
>
> +#define TPM_ERR_DEACTIVATED 0x6
> +#define TPM_ERR_DISABLED0x7
> +
> struct tpm_chip;
> struct trusted_key_payload;
> struct trusted_key_options;
> diff --git a/security/keys/trusted.c b/security/keys/trusted.c
> index 9a94672e7adc..430d85090b3b 100644
> --- a/security/keys/trusted.c
> +++ b/security/keys/trusted.c
> @@ -389,6 +389,10 @@ static int pcrlock(const int pcrnum)
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> + /* This can happen if the TPM is inactive. */
> + if (!digests)
> + return -EINVAL;
> +
> return tpm_pcr_extend(chip, pcrnum, digests) ? -EINVAL : 0;
> }
>
> @@ -1233,7 +1237,7 @@ static int __init init_digests(void)
> int i;
>
> ret = tpm_get_random(chip, digest, TPM_MAX_DIGEST_SIZE);
> - if (ret < 0)
> + if (ret < 0 || ret == TPM_ERR_DEACTIVATED || ret == TPM_ERR_DISABLED)
> return ret;
As someone who hasn't looked at much of the TPM code, I would have
expected tpm_get_random() to return a positive value that only ever
indicates the number of random bytes saved to the buffer. From the
function documentation:
Return: number of random bytes read or a negative error value.
Despite the function documentation and as your patch suggests, I can
see that it is possible for tpm_transmit_cmd() to return
a positive value that's also returned by tpm_get_random() even though it
may not have filled the buffer when the TPM is in an
inactive/deactivated state.
I think there are other callers which are not prepared for positive
return values that indicate a failure to fill the buffer with random
data. For instance, the way that tpm_hwrng_read() is calling
tpm_get_random() looks a little worrisome.
This patch would likely fix the bug reported against eCryptfs
(https://bugzilla.kernel.org/show_bug.cgi?id=203953) but I can't help to
think that callers of tpm_get_random() would benefit from a more
consolidated approach of handling TPM_ERR_* return values rather than
handling them at this single call site.
Tyler
> if (ret < TPM_MAX_DIGEST_SIZE)
> return -EFAULT;
> --
> 2.17.1
>
Re: [GIT pull] x86/pti for 5.3-rc1
On Mon, 8 Jul 2019, Linus Torvalds wrote:
> On Mon, Jul 8, 2019 at 2:22 AM Thomas Gleixner wrote:
> >
> > @@ -643,9 +644,11 @@ static unsigned long ptrace_get_debugreg(struct
> > task_struct *tsk, int n)
> > {
> > struct thread_struct *thread = >thread;
> > unsigned long val = 0;
> > + int index = n;
> >
> > if (n < HBP_NUM) {
> > - struct perf_event *bp = thread->ptrace_bps[n];
> > + index = array_index_nospec(index, HBP_NUM);
> > + struct perf_event *bp = thread->ptrace_bps[index];
>
> This causes a new warning:
>
>warning: ISO C90 forbids mixed declarations and code
>
> and I'm fixing it up in the merge as follows:
Ooops. No idea how that slipped through. Sorry!
> @@@ -633,9 -644,11 +634,10 @@@ static unsigned long ptrace_get_debugre
> {
> struct thread_struct *thread = >thread;
> unsigned long val = 0;
> - int index = n;
>
> if (n < HBP_NUM) {
> - struct perf_event *bp = thread->ptrace_bps[n];
> - index = array_index_nospec(index, HBP_NUM);
> ++ int index = array_index_nospec(n, HBP_NUM);
> + struct perf_event *bp = thread->ptrace_bps[index];
>
> if (bp)
> val = bp->hw.info.address;
>
> Holler if I did something stupid.
Obviously correct.
Thanks for fixing it up.
tglx
Re: [PATCH v3 6/7] dt-bindings: net: realtek: Add property to configure LED mode
On Mon, Jul 08, 2019 at 12:24:58PM -0700, Matthias Kaehlcke wrote: > The LED behavior of some Realtek PHYs is configurable. Add the > property 'realtek,led-modes' to specify the configuration of the > LEDs. > > Signed-off-by: Matthias Kaehlcke Hi Matthias Humm. I thought you were going to drop this and the next patch? Andrew
Re: [PATCH v3 1/7] dt-bindings: net: Add bindings for Realtek PHYs
On Mon, Jul 08, 2019 at 12:24:53PM -0700, Matthias Kaehlcke wrote: > Add the 'realtek,eee-led-mode-disable' property to disable EEE > LED mode on Realtek PHYs that support it. > > Signed-off-by: Matthias Kaehlcke > --- > TODO: adapt PHY core to deal with optional compatible strings Yes. Does this even work at the moment? I would expect of_mdiobus_child_is_phy() to return false, indicating the device is not actually a PHY. Andrew
Re: [PATCH 0/3] Update pcengines-apuv2 platform device
On 04.07.19 15:39, Andy Shevchenko wrote: > On Thu, Jul 4, 2019 at 12:02 PM Florian Eckert wrote: >> >> This patchset adds the following changes to this pcengines-apuv2 >> platform device. >> > > Before doing anything to this driver, what is the plan for previously > upstreamed: > > drivers/leds/leds-apu.c Only supports the three front LEDs, nothing else. (we've got more gpios that are not LEDs, eg. the front button, simsw, ...) > arch/x86/platform/geode/alix.c completely unrelated - very different chipset. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: m68k build failures in -next: undefined reference to `arch_dma_prep_coherent'
On Mon, Jul 08, 2019 at 09:13:02PM +0200, Geert Uytterhoeven wrote:
> Hi Günter,
>
> On Mon, Jul 8, 2019 at 7:06 PM Guenter Roeck wrote:
> > I see the following build error in -next:
> >
> > kernel/dma/direct.o: In function `dma_direct_alloc_pages':
> > direct.c:(.text+0x4d8): undefined reference to `arch_dma_prep_coherent'
> >
> > Example: m68k:allnoconfig.
> >
> > Bisect log is ambiguous and points to the merge of m68k/for-next into
> > -next. Yet, I think the problem is with commit 69878ef47562 ("m68k:
> > Implement arch_dma_prep_coherent()") which is supposed to introduce
> > the function. The problem is likely that arch_dma_prep_coherent()
> > is only declared if CONFIG_MMU is enabled, but it is called from code
> > outside CONFIG_MMU.
>
> Thanks, one more thing to fix in m68k-allnoconfig (did it really build
> before?)...
>
> Given you say "example", does it fail in real configs, too?
>
Yes, it does. All nommu builds fail. allnoconfig and tinyconfig just
happen to be among those.
Building m68k:allnoconfig ... failed
Building m68k:tinyconfig ... failed
Building m68k:m5272c3_defconfig ... failed
Building m68k:m5307c3_defconfig ... failed
Building m68k:m5249evb_defconfig ... failed
Building m68k:m5407c3_defconfig ... failed
Building m68k:m5475evb_defconfig ... failed
Error is always the same.
The error started with next-20190702. Prior to that, builds were fine,
including m68k:allnoconfig and m68k:tinyconfig.
Guenter
Re: [PATCH 1/3] platform/x86/pcengines-apuv2: add mpcie reset gpio export
On 04.07.19 11:02, Florian Eckert wrote: > On APUx we have also mpcie2/mpcie3 reset pins. To make it possible to reset > the ports from the userspace, add the definition to this platform > device. The gpio can then be exported by the legancy gpio subsystem to > toggle the mpcie reset pin. Are you sure they're also available on APUv2 (not just v3) ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH 2/3] platform/x86/pcengines-apuv2: add legacy leds gpio definitions
On 04.07.19 11:02, Florian Eckert wrote: > Extend the apu2_leds definition to make the leds exportable via the > legacy gpio subsystem. What for ? The gpios are bound to LED devices as that's exactly what they are: LEDs. > Without this change the leds are not visible > under "/sys/class/leds" and could not be configured. How so ? (I'm using exactly that all the day ...) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH] [net-next] macb: fix build warning for !CONFIG_OF
From: Arnd Bergmann
Date: Mon, 8 Jul 2019 14:48:23 +0200
> When CONFIG_OF is disabled, we get a harmless warning about the
> newly added variable:
>
> drivers/net/ethernet/cadence/macb_main.c:48:39: error: 'mgmt' defined but not
> used [-Werror=unused-variable]
> static struct sifive_fu540_macb_mgmt *mgmt;
>
> Move the variable closer to its use inside of the #ifdef.
>
> Fixes: c218ad559020 ("macb: Add support for SiFive FU540-C000")
> Signed-off-by: Arnd Bergmann
Applied, thanks Arnd.
RE: [PATCH 1/2] rtc/fsl: add FTM alarm driver as the wakeup source
> -Original Message-
> From: Biwen Li
> Sent: Friday, July 5, 2019 5:18 AM
> To: a.zu...@towertech.it; alexandre.bell...@bootlin.com; Leo Li
>
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Xiaobo Xie
> ; Jiafei Pan ; Ran Wang
> ; Biwen Li
> Subject: [PATCH 1/2] rtc/fsl: add FTM alarm driver as the wakeup source
>
> For the paltforms including LS1012A, LS1021A, LS1028A, LS1043A, LS1046A,
> LS1088A, LS208xA that has the FlexTimer module, implementing alarm
> functions within RTC subsystem to wakeup the system when system going to
> sleep.
>
> Signed-off-by: Biwen Li
> ---
> drivers/rtc/Kconfig | 14 ++
> drivers/rtc/Makefile| 1 +
> drivers/rtc/rtc-fsl-ftm-alarm.c | 417
>
> 3 files changed, 432 insertions(+)
> create mode 100644 drivers/rtc/rtc-fsl-ftm-alarm.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 03b60d5..0758a08
> 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1313,6 +1313,20 @@ config RTC_DRV_IMXDI
> This driver can also be built as a module, if so, the module
> will be called "rtc-imxdi".
>
> +config RTC_DRV_FSL_FTM_ALARM
> + tristate "Freescale FlexTimer alarm timer"
> + depends on ARCH_LAYERSCAPE
> + default y
> + help
> +For the FlexTimer in LS1012A, LS1021A, LS1028A, LS1043A, LS1046A,
> +LS1088A, LS208xA, we can use FTM as the wakeup source.
> +
> +Say y here to enable FTM alarm support. The FTM alarm provides
> +alarm functions for wakeup system from deep sleep.
> +
> +This driver can also be built as a module, if so, the module
> +will be called "rtc-fsl-ftm-alarm".
> +
> config RTC_DRV_MESON
> tristate "Amlogic Meson RTC"
> depends on (ARM && ARCH_MESON) || COMPILE_TEST diff --git
> a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 9d997fa..5cccb07 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -79,6 +79,7 @@ obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-
> hid-sensor-time.o
> obj-$(CONFIG_RTC_DRV_HYM8563)+= rtc-hym8563.o
> obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o
> obj-$(CONFIG_RTC_DRV_IMX_SC) += rtc-imx-sc.o
> +obj-$(CONFIG_RTC_DRV_FSL_FTM_ALARM) += rtc-fsl-ftm-alarm.o
> obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
> obj-$(CONFIG_RTC_DRV_ISL12026) += rtc-isl12026.o
> obj-$(CONFIG_RTC_DRV_ISL1208)+= rtc-isl1208.o
> diff --git a/drivers/rtc/rtc-fsl-ftm-alarm.c b/drivers/rtc/rtc-fsl-ftm-alarm.c
> new file mode 100644 index 000..e4075f0
> --- /dev/null
> +++ b/drivers/rtc/rtc-fsl-ftm-alarm.c
> @@ -0,0 +1,417 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Freescale FlexTimer Module (FTM) alarm device driver.
> + *
> + * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2019 NXP
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_MASK_SHIFT)
> +
> +/*
> + * Select Fixed frequency clock as clock source
> + * of FlexTimer Module
> + */
> +#define FTM_SC_CLKS_FIXED_FREQ 0x02
> +
> +#define FIXED_FREQ_CLK 32000
> +#define MAX_FREQ_DIV (1 << FTM_SC_PS_MASK)
> +#define MAX_COUNT_VAL0x
> +
> +struct ftm_rtc {
> + struct rtc_device *rtc_dev;
> + void __iomem *base;
> + bool endian;
> + u32 alarm_freq;
> +};
> +
> +enum pmu_endian_type {
> + BIG_ENDIAN,
> + LITTLE_ENDIAN,
> +};
> +
> +/*
> + * rcpm (Run Control and Power Management)
> + * is another IP block,different IP block
> + * has different endianness,so add new element
> + * big_endian to struct rcpm_cfg.
> + */
> +struct rcpm_cfg {
> + enum pmu_endian_type big_endian; /* Big/Little endian of PMU
> module */
> + u32 flextimer_set_bit; /* FTM is not powerdown during device
> sleep */
> +};
> +
> +static struct rcpm_cfg default_rcpm_cfg = {
> + .big_endian = LITTLE_ENDIAN,
> + .flextimer_set_bit = 0x4000,
> +};
> +
> +static struct rcpm_cfg ls1012a_rcpm_cfg = {
> + .big_endian = BIG_ENDIAN,
> + .flextimer_set_bit = 0x2,
> +};
> +
> +static struct rcpm_cfg ls1021a_rcpm_cfg = {
> + .big_endian = BIG_ENDIAN,
> + .flextimer_set_bit = 0x2,
> +};
> +
> +static struct rcpm_cfg ls1043a_rcpm_cfg = {
> + .big_endian = BIG_ENDIAN,
> + .flextimer_set_bit = 0x2,
> +};
> +
> +static struct rcpm_cfg ls1046a_rcpm_cfg = {
> + .big_endian = BIG_ENDIAN,
> + .flextimer_set_bit = 0x2,
> +};
> +
> +static struct rcpm_cfg ls1088a_rcpm_cfg = {
> +
Re: [PATCH net] net: stmmac: Re-work the queue selection for TSO packets
From: Jose Abreu
Date: Mon, 8 Jul 2019 14:26:28 +0200
> Ben Hutchings says:
> "This is the wrong place to change the queue mapping.
> stmmac_xmit() is called with a specific TX queue locked,
> and accessing a different TX queue results in a data race
> for all of that queue's state.
>
> I think this commit should be reverted upstream and in all
> stable branches. Instead, the driver should implement the
> ndo_select_queue operation and override the queue mapping there."
>
> Fixes: c5acdbee22a1 ("net: stmmac: Send TSO packets always from Queue 0")
> Suggested-by: Ben Hutchings
> Signed-off-by: Jose Abreu
Applied and queued up for -stable.
Re: [PATCH] [net-next] gve: fix unused variable/label warnings
From: Arnd Bergmann
Date: Mon, 8 Jul 2019 14:43:39 +0200
> On unusual page sizes, we get harmless warnings:
>
> drivers/net/ethernet/google/gve/gve_rx.c:283:6: error: unused variable
> 'pagecount' [-Werror,-Wunused-variable]
> drivers/net/ethernet/google/gve/gve_rx.c:336:1: error: unused label
> 'have_skb' [-Werror,-Wunused-label]
>
> Change the preprocessor #if to regular if() to avoid this.
>
> Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
> Signed-off-by: Arnd Bergmann
Applied.
Re: [PATCH 0/3] Update pcengines-apuv2 platform device
On 05.07.19 13:36, Florian Eckert wrote: Hi, > APU1 (PC-Engines) CPU "AMD G series T40E APU":> This is also an old design > and is not recommend for new design> (deprecated).> Also not many were produced and are in the field.> See https://pcengines.ch/apu.htm Yes, and I haven't been able to get one yet, so I dropped my original plan of supporting this once. The gpio device is very different. > Platform-Device (LEDs, Button):> I have no platform device description found > in the linux sources.> So the GPIO button should not work. Talking about the old driver ? It only supports the three front LEDs directly and conflicts w/ anything else that wants to support other GPIOs. > Platform-Device (LEDs, Button): > This Platform description is only valid for APU2/APU3 and not for APU1. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/pcengines-apuv2.c Correct. If we really wanna support APUv1, that most likely become a completely separate driver, as the chipsets are very different. > LEDs-Driver: > We have an additional device only for LEDs this works for APU1/APU2/APU3. > I think we should remove the APU2/APU3 LEDs from the leds-apu device as > mentioned above. > So this device supports only the APU1 LEDs. ACK. > We could extend and/or rename the pcengienes-apuv2 device to support > also APU3 and the newest APU4. APUv3 already is supported. APUv4 again is pretty different, and I don't have one yet. (if anybody convices pcengines to give me some boards, I'll add support for them :)) > The APU3 does have an additional the simswap pin. Already planned to add it, but not yet sorted into which subsystem it actually belongs to. > We should change this to the following layout and add the legacy GPIO > numbering. First we'll have to sort out where the new pins actually belong into. (maybe power management / regulators for the reset pins ?) > ALIX (PC-Engines) CPU "AMD Geode LX": > This is an old design we have already in use and is not recommend for > new design (deprecated) > https://pcengines.ch/alix.htm And it's an entirely different chipset, not related at all to apu. > I think we should leave the driver as it is because this is a different > design and has nothing to do with the PUs. Yes. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH v3] RDMA/core: Fix race when resolving IP address
On Mon, Jul 08, 2019 at 07:22:45PM +, Mark Bloch wrote: > > > On 7/8/19 11:47 AM, Dag Moxnes wrote: > > Thanks Jason, > > > > Regards, > > Dag > > > > Den 08.07.2019 19:50, skrev Jason Gunthorpe: > >> On Mon, Jul 08, 2019 at 01:16:24PM +0200, Dag Moxnes wrote: > >>> Use neighbour lock when copying MAC address from neighbour data struct > >>> in dst_fetch_ha. > >>> > >>> When not using the lock, it is possible for the function to race with > >>> neigh_update, causing it to copy an invalid MAC address. > >>> > >>> It is possible to provoke this error by calling rdma_resolve_addr in a > >>> tight loop, while deleting the corresponding ARP entry in another tight > >>> loop. > >>> > >>> This will cause the race shown it the following sample trace: > >>> > >>> rdma_resolve_addr() > >>> rdma_resolve_ip() > >>> addr_resolve() > >>> addr_resolve_neigh() > >>> fetch_ha() > >>> dst_fetch_ha() > >>> n->nud_state == NUD_VALID > >> It isn't nud_state that is the problem here, it is the parallel > >> memcpy's onto ha. I fixed the commit message > >> > >> This could also have been solved by using the ha_lock, but I don't > >> think we have a reason to particularly over-optimize this. > > Sorry I'm late to the party, but why not just use: neigh_ha_snapshot()? Yes, that is much better, please respin this Thanks, Jason
kernel BUG at lib/lockref.c:LINE!
Hello, syzbot found the following crash on: HEAD commit:d58b5ab9 Add linux-next specific files for 20190708 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=123d6887a0 kernel config: https://syzkaller.appspot.com/x/.config?x=bf9882946ecc11d9 dashboard link: https://syzkaller.appspot.com/bug?extid=f70e9b00f8c7d4187bd0 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=173375c7a0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1536f9bfa0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+f70e9b00f8c7d4187...@syzkaller.appspotmail.com [ cut here ] kernel BUG at lib/lockref.c:189! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 0 PID: 9350 Comm: syz-executor444 Not tainted 5.2.0-next-20190708 #33 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:lockref_mark_dead lib/lockref.c:189 [inline] RIP: 0010:lockref_mark_dead+0x8b/0xa0 lib/lockref.c:187 Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 04 3c 03 7e 1d c7 43 38 80 ff ff ff 5b 41 5c 5d c3 e8 75 19 38 fe <0f> 0b 48 89 df e8 0b 59 72 fe eb ab e8 a4 59 72 fe eb dc 90 90 55 RSP: 0018:88809004fc90 EFLAGS: 00010293 RAX: 88808bcc0300 RBX: 8880a69b0520 RCX: 833a3abf RDX: RSI: 833a3afb RDI: 0005 RBP: 88809004fca0 R08: 88808bcc0300 R09: ed1014d360a5 R10: ed1014d360a4 R11: 8880a69b0523 R12: R13: 8880a69b0520 R14: 8880a69b04a0 R15: FS: 5571f880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55738938 CR3: 91be1000 CR4: 001406f0 Call Trace: __dentry_kill+0x5f/0x600 fs/dcache.c:560 shrink_dcache_parent+0x2c9/0x3d0 fs/dcache.c:1565 vfs_rmdir fs/namei.c:3882 [inline] vfs_rmdir+0x26f/0x4f0 fs/namei.c:3857 do_rmdir+0x39e/0x420 fs/namei.c:3940 __do_sys_rmdir fs/namei.c:3958 [inline] __se_sys_rmdir fs/namei.c:3956 [inline] __x64_sys_rmdir+0x36/0x40 fs/namei.c:3956 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441917 Code: 0f 1f 00 b8 57 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 ad 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 54 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 8d 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffe53fc08f8 EFLAGS: 0207 ORIG_RAX: 0054 RAX: ffda RBX: 0065 RCX: 00441917 RDX: RSI: RDI: 7ffe53fc1a90 RBP: 24ef R08: R09: 0001 R10: 0005 R11: 0207 R12: 7ffe53fc1a90 R13: 557288c0 R14: R15: Modules linked in: ---[ end trace 407254279c8c4b61 ]--- RIP: 0010:lockref_mark_dead lib/lockref.c:189 [inline] RIP: 0010:lockref_mark_dead+0x8b/0xa0 lib/lockref.c:187 Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 04 3c 03 7e 1d c7 43 38 80 ff ff ff 5b 41 5c 5d c3 e8 75 19 38 fe <0f> 0b 48 89 df e8 0b 59 72 fe eb ab e8 a4 59 72 fe eb dc 90 90 55 RSP: 0018:88809004fc90 EFLAGS: 00010293 RAX: 88808bcc0300 RBX: 8880a69b0520 RCX: 833a3abf RDX: RSI: 833a3afb RDI: 0005 RBP: 88809004fca0 R08: 88808bcc0300 R09: ed1014d360a5 R10: ed1014d360a4 R11: 8880a69b0523 R12: R13: 8880a69b0520 R14: 8880a69b04a0 R15: FS: 5571f880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55738938 CR3: 91be1000 CR4: 001406f0 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
WARNING: held lock freed! (2)
Hello,
syzbot found the following crash on:
HEAD commit:9d1bc24b bonding: validate ip header before check IPPROTO_..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=152fab25a0
kernel config: https://syzkaller.appspot.com/x/.config?x=e7c31a94f66cc0aa
dashboard link: https://syzkaller.appspot.com/bug?extid=e54ed2cb16c6da22c549
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11ad60bba0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=165d2453a0
The bug was bisected to:
commit c8c8218ec5af5d2598381883acbefbf604e56b5e
Author: Cong Wang
Date: Thu Jun 27 21:30:58 2019 +
netrom: fix a memory leak in nr_rx_frame()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1489854ba0
final crash:https://syzkaller.appspot.com/x/report.txt?x=1689854ba0
console output: https://syzkaller.appspot.com/x/log.txt?x=1289854ba0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e54ed2cb16c6da22c...@syzkaller.appspotmail.com
Fixes: c8c8218ec5af ("netrom: fix a memory leak in nr_rx_frame()")
=
WARNING: held lock freed!
5.2.0-rc6+ #75 Not tainted
-
syz-executor315/8559 is freeing memory 88809faed2c0-88809faedabf,
with a lock still held there!
cf45dbdb (sk_lock-AF_NETROM){+.+.}, at: lock_sock
include/net/sock.h:1522 [inline]
cf45dbdb (sk_lock-AF_NETROM){+.+.}, at: nr_release+0x11a/0x3b0
net/netrom/af_netrom.c:522
2 locks held by syz-executor315/8559:
#0: c0a19dcd (>s_type->i_mutex_key#11){+.+.}, at: inode_lock
include/linux/fs.h:778 [inline]
#0: c0a19dcd (>s_type->i_mutex_key#11){+.+.}, at:
__sock_release+0x89/0x2a0 net/socket.c:600
#1: cf45dbdb (sk_lock-AF_NETROM){+.+.}, at: lock_sock
include/net/sock.h:1522 [inline]
#1: cf45dbdb (sk_lock-AF_NETROM){+.+.}, at: nr_release+0x11a/0x3b0
net/netrom/af_netrom.c:522
stack backtrace:
CPU: 0 PID: 8559 Comm: syz-executor315 Not tainted 5.2.0-rc6+ #75
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_freed_lock_bug kernel/locking/lockdep.c:5077 [inline]
debug_check_no_locks_freed.cold+0x9d/0xa9 kernel/locking/lockdep.c:5110
kfree+0xb1/0x220 mm/slab.c:3752
sk_prot_free net/core/sock.c:1636 [inline]
__sk_destruct+0x4f7/0x6e0 net/core/sock.c:1722
sk_destruct+0x7b/0x90 net/core/sock.c:1730
__sk_free+0xce/0x300 net/core/sock.c:1741
sk_free+0x42/0x50 net/core/sock.c:1752
sock_put include/net/sock.h:1725 [inline]
nr_destroy_socket+0x3df/0x4a0 net/netrom/af_netrom.c:288
nr_release+0x323/0x3b0 net/netrom/af_netrom.c:530
__sock_release+0xce/0x2a0 net/socket.c:601
sock_close+0x1b/0x30 net/socket.c:1273
__fput+0x2ff/0x890 fs/file_table.c:280
fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:185 [inline]
exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:168
prepare_exit_to_usermode arch/x86/entry/common.c:199 [inline]
syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
do_syscall_64+0x58e/0x680 arch/x86/entry/common.c:304
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447269
Code: e8 7c 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb 0e fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f653a7bed88 EFLAGS: 0246 ORIG_RAX: 002d
RAX: ff95 RBX: 006dcc48 RCX: 00447269
RDX: RSI: RDI: 0003
RBP: 006dcc40 R08: R09:
R10: R11: 0246 R12: 006dcc4c
R13: 003066736362 R14: 002cc7eb4700 R15: 003066736362
==
BUG: KASAN: use-after-free in debug_spin_lock_before
kernel/locking/spinlock_debug.c:83 [inline]
BUG: KASAN: use-after-free in do_raw_spin_lock+0x28a/0x2e0
kernel/locking/spinlock_debug.c:112
Read of size 4 at addr 88809faed34c by task syz-executor315/8559
CPU: 1 PID: 8559 Comm: syz-executor315 Not tainted 5.2.0-rc6+ #75
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
__kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
kasan_report+0x12/0x20 mm/kasan/common.c:614
__asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x28a/0x2e0
possible deadlock in rtnl_lock (6)
Hello,
syzbot found the following crash on:
HEAD commit:537de0c8 ipv4: Fix NULL pointer dereference in ipv4_neigh_..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=14521cc3a0
kernel config: https://syzkaller.appspot.com/x/.config?x=90f5d2d9c1e7421c
dashboard link: https://syzkaller.appspot.com/bug?extid=174ce29c2308dec5bc68
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1777debba0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16969b53a0
The bug was bisected to:
commit 455302d1c9ae9318660aaeb9748a01ff414c9741
Author: Ilya Maximets
Date: Fri Jun 28 08:04:07 2019 +
xdp: fix hang while unregistering device bound to xdp socket
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1179943da0
final crash:https://syzkaller.appspot.com/x/report.txt?x=1379943da0
console output: https://syzkaller.appspot.com/x/log.txt?x=1579943da0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+174ce29c2308dec5b...@syzkaller.appspotmail.com
Fixes: 455302d1c9ae ("xdp: fix hang while unregistering device bound to xdp
socket")
==
WARNING: possible circular locking dependency detected
5.2.0-rc6+ #76 Not tainted
--
syz-executor613/9114 is trying to acquire lock:
2c564901 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:72
but task is already holding lock:
39d6ee9b (>mutex){+.+.}, at: xsk_bind+0x16a/0xe70
net/xdp/xsk.c:422
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (>mutex){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:926 [inline]
__mutex_lock+0xf7/0x1310 kernel/locking/mutex.c:1073
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
xsk_notifier+0x149/0x290 net/xdp/xsk.c:730
notifier_call_chain+0xc2/0x230 kernel/notifier.c:95
__raw_notifier_call_chain kernel/notifier.c:396 [inline]
raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1749
call_netdevice_notifiers_extack net/core/dev.c:1761 [inline]
call_netdevice_notifiers net/core/dev.c:1775 [inline]
rollback_registered_many+0x9b9/0xfc0 net/core/dev.c:8206
rollback_registered+0x109/0x1d0 net/core/dev.c:8248
unregister_netdevice_queue net/core/dev.c:9295 [inline]
unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9288
br_dev_delete+0x145/0x1a0 net/bridge/br_if.c:383
br_del_bridge+0xd7/0x120 net/bridge/br_if.c:483
br_ioctl_deviceless_stub+0x2a4/0x7b0 net/bridge/br_ioctl.c:376
sock_ioctl+0x44b/0x780 net/socket.c:1141
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (>xdp.lock){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:926 [inline]
__mutex_lock+0xf7/0x1310 kernel/locking/mutex.c:1073
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
xsk_notifier+0xa7/0x290 net/xdp/xsk.c:726
notifier_call_chain+0xc2/0x230 kernel/notifier.c:95
__raw_notifier_call_chain kernel/notifier.c:396 [inline]
raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1749
call_netdevice_notifiers_extack net/core/dev.c:1761 [inline]
call_netdevice_notifiers net/core/dev.c:1775 [inline]
rollback_registered_many+0x9b9/0xfc0 net/core/dev.c:8206
rollback_registered+0x109/0x1d0 net/core/dev.c:8248
unregister_netdevice_queue net/core/dev.c:9295 [inline]
unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9288
br_dev_delete+0x145/0x1a0 net/bridge/br_if.c:383
br_del_bridge+0xd7/0x120 net/bridge/br_if.c:483
br_ioctl_deviceless_stub+0x2a4/0x7b0 net/bridge/br_ioctl.c:376
sock_ioctl+0x44b/0x780 net/socket.c:1141
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (rtnl_mutex){+.+.}:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4303
__mutex_lock_common
Re: [PATCH v1 5/6] mm: Add logic for separating "aerated" pages from "raw" pages
On 7/8/19 12:02 PM, Alexander Duyck wrote:
> On Tue, 2019-06-25 at 13:24 -0700, Dave Hansen wrote:
>> I also don't see what the boundary has to do with aerated pages being on
>> the tail of the list. If you want them on the tail, you just always
>> list_add_tail() them.
>
> The issue is that there are multiple things that can add to the tail of
> the list. For example the shuffle code or the lower order buddy expecting
> its buddy to be freed. In those cases I don't want to add to tail so
> instead I am adding those to the boundary. By doing that I can avoid
> having the tail of the list becoming interleaved with raw and aerated
> pages.
So, it sounds like we've got the following data structure rules:
1. We have one list_head and one list of pages
2. For the purposes of allocation, the list is treated the same as
before these patches
3. For a "free()", the behavior changes and we now have two "tails":
3a. Aerated pages are freed into the tail of the list
3b. Cold pages are freed at the boundary between aerated and non.
This serves to... This is also referred to as a "tail".
3a. Hot pages are never aerated and are still freed into the head
of the list.
Did I miss any? Could you please spell it out this way in future
changelogs?
>>> +struct list_head *__aerator_get_tail(unsigned int order, int migratetype);
>>> static inline struct list_head *aerator_get_tail(struct zone *zone,
>>> unsigned int order,
>>> int migratetype)
>>> {
>>> +#ifdef CONFIG_AERATION
>>> + if (order >= AERATOR_MIN_ORDER &&
>>> + test_bit(ZONE_AERATION_ACTIVE, >flags))
>>> + return __aerator_get_tail(order, migratetype);
>>> +#endif
>>> return >free_area[order].free_list[migratetype];
>>> }
>>
>> Logically, I have no idea what this is doing. "Go get pages out of the
>> aerated list?" "raw list"? Needs comments.
>
> I'll add comments. Really now that I think about it I should probably
> change the name for this anyway. What is really being returned is the tail
> for the non-aerated list. Specifically if ZONE_AERATION_ACTIVE is set we
> want to prevent any insertions below the list of aerated pages, so we are
> returning the first entry in the aerated list and using that as the
> tail/head of a list tail insertion.
>
> Ugh. I really need to go back and name this better.
OK, so we now have two tails? One that's called both a boundary and a
tail at different parts of the code?
>>> static inline void aerator_notify_free(struct zone *zone, int order)
>>> {
>>> +#ifdef CONFIG_AERATION
>>> + if (!static_key_false(_notify_enabled))
>>> + return;
>>> + if (order < AERATOR_MIN_ORDER)
>>> + return;
>>> + if (test_bit(ZONE_AERATION_REQUESTED, >flags))
>>> + return;
>>> + if (aerator_raw_pages(>free_area[order]) < AERATOR_HWM)
>>> + return;
>>> +
>>> + __aerator_notify(zone);
>>> +#endif
>>> }
>>
>> Again, this is really hard to review. I see some possible overhead in a
>> fast path here, but only if aerator_notify_free() is called in a fast
>> path. Is it? I have to go digging in the previous patches to figure
>> that out.
>
> This is called at the end of __free_one_page().
>
> I tried to limit the impact as much as possible by ordering the checks the
> way I did. The order check should limit the impact pretty significantly as
> that is the only one that will be triggered for every page, then the
> higher order pages are left to deal with the test_bit and
> aerator_raw_pages checks.
That sounds like a good idea. But, that good idea is very hard to
distill from the code in the patch.
Imagine if the function stared being commented with:
/* Called from a hot path in __free_one_page() */
And said:
if (!static_key_false(_notify_enabled))
return;
/* Avoid (slow) notifications when no aeration is performed: */
if (order < AERATOR_MIN_ORDER)
return;
if (test_bit(ZONE_AERATION_REQUESTED, >flags))
return;
/* Some other relevant comment: */
if (aerator_raw_pages(>free_area[order]) < AERATOR_HWM)
return;
/* This is slow, but should happen very rarely: */
__aerator_notify(zone);
>>> +static void aerator_populate_boundaries(struct zone *zone)
>>> +{
>>> + unsigned int order, mt;
>>> +
>>> + if (test_bit(ZONE_AERATION_ACTIVE, >flags))
>>> + return;
>>> +
>>> + for_each_aerate_migratetype_order(order, mt)
>>> + aerator_reset_boundary(zone, order, mt);
>>> +
>>> + set_bit(ZONE_AERATION_ACTIVE, >flags);
>>> +}
>>
>> This function appears misnamed as it's doing more than boundary
>> manipulation.
>
> The ZONE_AERATION_ACTIVE flag is what is used to indicate that the
> boundaries are being tracked. Without that we just fall back to using the
> free_list tail.
Is the flag used for other
Re: [PATCH v8 06/11] x86/CPU: Adapt assembly for PIE support
On Mon, Jul 8, 2019 at 12:09 PM Alexey Dobriyan wrote: > > Thomas Garnier wrote: > > - "pushq $1f\n\t" > > + "movabsq $1f, %q0\n\t" > > + "pushq %q0\n\t" > > "iretq\n\t" > > UNWIND_HINT_RESTORE > > "1:" > > Fake PIE. True PIE looks like this: I used movabsq in couple assembly changes where the memory context is unclear and relative reference might lead to issues. It happened on early boot and hibernation save/restore paths. Do you think a relative reference in this function will always be accurate? > > 81022d70 : > 81022d70: 8c d0 moveax,ss > 81022d72: 50 push rax > 81022d73: 54 push rsp > 81022d74: 48 83 04 24 08 addQWORD PTR [rsp],0x8 > 81022d79: 9c pushf > 81022d7a: 8c c8 moveax,cs > 81022d7c: 50 push rax > 81022d7d: ===> 48 8d 05 03 00 00 00learax,[rip+0x3]# > 81022d87 > 81022d84: 50 push rax > 81022d85: 48 cf iretq > 81022d87: c3 ret > > Signed-off-by: Alexey Dobriyan > > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -710,7 +710,8 @@ static inline void sync_core(void) > "pushfq\n\t" > "mov %%cs, %0\n\t" > "pushq %q0\n\t" > - "pushq $1f\n\t" > + "leaq 1f(%%rip), %q0\n\t" > + "pushq %q0\n\t" > "iretq\n\t" > UNWIND_HINT_RESTORE > "1:"
Re: [RFC PATCH] x86: Remove X86_FEATURE_MFENCE_RDTSC
On 7/4/19 10:46 AM, Josh Poimboeuf wrote:
> AMD and Intel both have serializing lfence (X86_FEATURE_LFENCE_RDTSC).
> They've both had it for a long time, and AMD has had it enabled in Linux
> since Spectre v1 was announced.
>
> Back then, there was a proposal to remove the serializing mfence feature
> bit (X86_FEATURE_MFENCE_RDTSC), since both AMD and Intel have
> serializing lfence. At the time, it was (ahem) speculated that some
> hypervisors might not yet support its removal, so it remained for the
> time being.
>
> Now a year-and-a-half later, it should be safe to remove.
I vaguely remember a concern from a migration point of view, maybe? Adding
Paolo to see if he has any concerns.
Thanks,
Tom
>
> I asked Andrew Cooper about whether it's still needed:
>
> So if you're virtualised, you've got no choice in the matter. lfence
> is either dispatch-serialising or not on AMD, and you won't be able to
> change it.
>
> Furthermore, you can't accurately tell what state the bit is in, because
> the MSR might not be virtualised at all, or may not reflect the true
> state in hardware. Worse still, attempting to set the bit may not be
> successful even if there isn't a fault for doing so.
>
> Xen sets the DE_CFG bit unconditionally, as does Linux by the looks of
> things (see MSR_F10H_DECFG_LFENCE_SERIALIZE_BIT). ISTR other hypervisor
> vendors saying the same, but I don't have any information to hand.
>
> If you are running under a hypervisor which has been updated, then
> lfence will almost certainly be dispatch-serialising in practice, and
> you'll almost certainly see the bit already set in DE_CFG. If you're
> running under a hypervisor which hasn't been patched since Spectre,
> you've already lost in many more ways.
>
> I'd argue that X86_FEATURE_MFENCE_RDTSC is not worth keeping.
>
> So remove it. This will reduce some code rot, and also make it easier
> to hook barrier_nospec() up to a cmdline disable for performance
> raisins, without having to need an alternative_3() macro.
>
> Signed-off-by: Josh Poimboeuf
> Cc: Tom Lendacky
> Cc: Andrew Cooper
> Cc: Thomas Gleixner
> Cc: Pu Wen
> Cc: Borislav Petkov
> ---
> arch/x86/include/asm/barrier.h | 3 +--
> arch/x86/include/asm/cpufeatures.h | 1 -
> arch/x86/include/asm/msr.h | 3 +--
> arch/x86/kernel/cpu/amd.c| 21 +++--
> arch/x86/kernel/cpu/hygon.c | 21 +++--
> tools/arch/x86/include/asm/cpufeatures.h | 1 -
> 6 files changed, 8 insertions(+), 42 deletions(-)
>
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index 84f848c2541a..7f828fe49797 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -49,8 +49,7 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> #define array_index_mask_nospec array_index_mask_nospec
>
> /* Prevent speculative execution past this barrier. */
> -#define barrier_nospec() alternative_2("", "mfence",
> X86_FEATURE_MFENCE_RDTSC, \
> -"lfence", X86_FEATURE_LFENCE_RDTSC)
> +#define barrier_nospec() alternative("", "lfence", X86_FEATURE_LFENCE_RDTSC)
>
> #define dma_rmb()barrier()
> #define dma_wmb()barrier()
> diff --git a/arch/x86/include/asm/cpufeatures.h
> b/arch/x86/include/asm/cpufeatures.h
> index 998c2cc08363..9b98edb6b2d3 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -96,7 +96,6 @@
> #define X86_FEATURE_SYSCALL32( 3*32+14) /* "" syscall in
> IA32 userspace */
> #define X86_FEATURE_SYSENTER32 ( 3*32+15) /* "" sysenter in
> IA32 userspace */
> #define X86_FEATURE_REP_GOOD ( 3*32+16) /* REP microcode works well
> */
> -#define X86_FEATURE_MFENCE_RDTSC ( 3*32+17) /* "" MFENCE synchronizes
> RDTSC */
> #define X86_FEATURE_LFENCE_RDTSC ( 3*32+18) /* "" LFENCE synchronizes
> RDTSC */
> #define X86_FEATURE_ACC_POWER( 3*32+19) /* AMD Accumulated
> Power Mechanism */
> #define X86_FEATURE_NOPL ( 3*32+20) /* The NOPL (0F 1F)
> instructions */
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 5cc3930cb465..86f20d520a07 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -233,8 +233,7 @@ static __always_inline unsigned long long
> rdtsc_ordered(void)
>* Thus, use the preferred barrier on the respective CPU, aiming for
>* RDTSCP as the default.
>*/
> - asm volatile(ALTERNATIVE_3("rdtsc",
> -"mfence; rdtsc", X86_FEATURE_MFENCE_RDTSC,
> + asm volatile(ALTERNATIVE_2("rdtsc",
> "lfence; rdtsc", X86_FEATURE_LFENCE_RDTSC,
> "rdtscp", X86_FEATURE_RDTSCP)
> : EAX_EDX_RET(val, low, high)
> diff --git
Re: [PATCH 4.14 00/56] 4.14.133-stable review
stable-rc/linux-4.14.y boot: 105 boots: 3 failed, 101 passed with 1 untried/unknown (v4.14.132-57-gb33dcbc2d8e5) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.132-57-gb33dcbc2d8e5/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.132-57-gb33dcbc2d8e5/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.132-57-gb33dcbc2d8e5 Git Commit: b33dcbc2d8e56734ead69d9d6808090159b19dab Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 61 unique boards, 24 SoC families, 15 builds out of 201 Boot Failures Detected: arm: sunxi_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab multi_v7_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab arm64: defconfig: gcc-8: rk3399-firefly: 1 failed lab --- For more info write to
Re: [GIT pull] x86/entry for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-entry-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0d37dde70655be73575d011be1bffaf0e3b16ea9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] timers/core for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > timers-core-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/927ba67a63c72ee87d655e30183d1576c3717d3e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] irq/core for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2a1ccd31420a7b1acd6ca37b2bec2d723aa093e4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] x86/fpu for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-fpu-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ab2486a9ee3243c8342549f58a13cdfa9abb497a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] x86/pti for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/223cea6a4f0552b86fb25e3b8bbd00469816cd7a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] smp/hotplug for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > smp-hotplug-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e0e86b111bca6bbf746c03ec5cf3e6a61fa3f8e9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] core/rslib for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rslib-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/568521d058aaab18f01ac39d7a6ef00b75e5cc79 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] x86/apic for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-apic-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0902d5011cfaabd6a09326299ef77e1c8735fb89 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] x86/cpu for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cpu-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/13324c42c1401ad838208ee1e98f3821fce1cd86 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] x86/timers for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-timers-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2f0f6503e37551eb8d8d5e4d27c78d28a30fed5a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] arm64 updates for 5.3
The pull request you sent on Thu, 4 Jul 2019 16:54:29 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/dfd437a257924484b144ee750e60affc95562c6d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 5.1 00/96] 5.1.17-stable review
On Mon, Jul 08, 2019 at 05:12:32PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.1.17 release. > There are 96 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 know. > > Responses should be made by Wed 10 Jul 2019 03:03:52 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.17-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.1.y > and the diffstat can be found below. > > thanks, > > greg k-h > > - Hi Greg, Compiled and Booted on my x86_64 system. Thanks, - Luke
Re: [GIT PULL] s390 patches for the 5.3 merge window
The pull request you sent on Mon, 8 Jul 2019 10:22:54 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git s390-5.3-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1758feddb0f9751debdc865fefde94b45907c948 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull] core/debugobjects for 5.3-rc1
The pull request you sent on Mon, 08 Jul 2019 09:05:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > core-debugobjects-for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6b37754790067c9b25cf75fbf72b69edd6d7fffd Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] m68k updates for 5.3
The pull request you sent on Mon, 8 Jul 2019 10:00:05 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git > tags/m68k-for-v5.3-tag1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/278ecbf027c3c559deb225f0cf53a23b7672dacf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
Mon, Jul 08, 2019 at 09:26:29PM CEST, j...@resnulli.us wrote: >Mon, Jul 08, 2019 at 07:27:29PM CEST, mkube...@suse.cz wrote: >>On Wed, Jul 03, 2019 at 10:41:51AM +0200, Jiri Pirko wrote: >>> Tue, Jul 02, 2019 at 04:52:41PM CEST, mkube...@suse.cz wrote: >>> >On Tue, Jul 02, 2019 at 02:25:21PM +0200, Jiri Pirko wrote: >>> >> Tue, Jul 02, 2019 at 01:49:59PM CEST, mkube...@suse.cz wrote: >>> >> >+ >>> >> >+ETHTOOL_A_HEADER_DEV_INDEX (u32) device ifindex >>> >> >+ETHTOOL_A_HEADER_DEV_NAME (string)device name >>> >> >+ETHTOOL_A_HEADER_INFOMASK (u32) info mask >>> >> >+ETHTOOL_A_HEADER_GFLAGS(u32) flags common for all >>> >> >requests >>> >> >+ETHTOOL_A_HEADER_RFLAGS(u32) request specific flags >>> >> >+ >>> >> >+ETHTOOL_A_HEADER_DEV_INDEX and ETHTOOL_A_HEADER_DEV_NAME identify the >>> >> >device >>> >> >+message relates to. One of them is sufficient in requests, if both are >>> >> >used, >>> >> >+they must identify the same device. Some requests, e.g. global string >>> >> >sets, do >>> >> >+not require device identification. Most GET requests also allow dump >>> >> >requests >>> >> >+without device identification to query the same information for all >>> >> >devices >>> >> >+providing it (each device in a separate message). >>> >> >+ >>> >> >+Optional info mask allows to ask only for a part of data provided by >>> >> >GET >>> >> >>> >> How this "infomask" works? What are the bits related to? Is that request >>> >> specific? >>> > >>> >The interpretation is request specific, the information returned for >>> >a GET request is divided into multiple parts and client can choose to >>> >request one of them (usually one). In the code so far, infomask bits >>> >correspond to top level (nest) attributes but I would rather not make it >>> >a strict rule. >>> >>> Wait, so it is a matter of verbosity? If you have multiple parts and the >>> user is able to chose one of them, why don't you rather have multiple >>> get commands, one per bit. This infomask construct seems redundant to me. >> >>I thought it was a matter of verbosity because it is a very basic >>element of the design, it was even advertised in the cover letter among >>the basic ideas, it has been there since the very beginning and in five >>previous versions through year and a half, noone did question it. That's >>why I thought you objected against unclear description, not against the >>concept as such. >> >>There are two reasons for this design. First is to reduce the number of >>requests needed to get the information. This is not so much a problem of >>ethtool itself; the only existing commands that would result in multiple >>request messages would be "ethtool " and "ethtool -s ". Maybe >>also "ethtool -x/-X " but even if the indirection table and hash >>key have different bits assigned now, they don't have to be split even >>if we split other commands. It may be bigger problem for daemons wanting >>to keep track of system configuration which would have to issue many >>requests whenever a new device appears. >> >>Second reason is that with 8-bit genetlink command/message id, the space >>is not as infinite as it might seem. I counted quickly, right now the >>full series uses 14 ids for kernel messages, with split you propose it >>would most likely grow to 44. For full implementation of all ethtool >>functionality, we could get to ~60 ids. It's still only 1/4 of the >>available space but it's not clear what the future development will look >>like. We would certainly need to be careful not to start allocating new >>commands for single parameters and try to be foreseeing about what can >>be grouped together. But we will need to do that in any case. >> >>On kernel side, splitting existing messages would make some things a bit >>easier. It would also reduce the number of scenarios where only part of >>requested information is available or only part of a SET request fails. > >Okay, I got your point. So why don't we look at if from the other angle. >Why don't we have only single get/set command that would be in general >used to get/set ALL info from/to the kernel. Where we can have these >bits (perhaps rather varlen bitfield) to for user to indicate which data >is he interested in? This scales. The other commands would be >just for action. > >Something like RTM_GETLINK/RTM_SETLINK. Makes sense? + I think this might safe a lot of complexicity aroung your proposed inner ops. > > >> >>Michal
Re: [PATCH 3/3] platform//x86/pcengines-apuv2: update gpio button definition
On 04.07.19 11:02, Florian Eckert wrote: > * Add the gpio number, so the button subsystem can find the right gpio. > * Change also the keycode from KEY_SETUP to KEY_RESTART, because it > seems more expressive to me and in the Alix-Board, which is the > predecessor, there isthis keycode defined too. I think this is also > intended by Pcengines. Also many embedded systems defined in the kernel > use this key code as well. In general, I'm not opposed to that, but I'll first have to check trough various userland code to make sure that it doesn't break anything in the field, before I can give my ack. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH v3] fs: Fix the default values of i_uid/i_gid on /proc/sys inodes.
On Mon, Jul 08, 2019 at 01:51:30PM +0200, Radoslaw Burny wrote:
> fs: Fix the default values of i_uid/i_gid on /proc/sys inodes.
> Normally, the inode's i_uid/i_gid are translated relative to s_user_ns,
> but this is not a correct behavior for proc. Since sysctl permission
> check in test_perm is done against GLOBAL_ROOT_[UG]ID, it makes more
> sense to use these values in u_[ug]id of proc inodes.
> In other words: although uid/gid in the inode is not read during
> test_perm, the inode logically belongs to the root of the namespace.
> I have confirmed this with Eric Biederman at LPC and in this thread:
> https://lore.kernel.org/lkml/87k1kzjdff@xmission.com
>
> Consequences
>
> Since the i_[ug]id values of proc nodes are not used for permissions
> checks, this change usually makes no functional difference. However, it
> causes an issue in a setup where:
> * a namespace container is created without root user in container -
> hence the i_[ug]id of proc nodes are set to INVALID_[UG]ID
> * container creator tries to configure it by writing /proc/sys files,
> e.g. writing /proc/sys/kernel/shmmax to configure shared memory limit
> Kernel does not allow to open an inode for writing if its i_[ug]id are
> invalid, making it impossible to write shmmax and thus - configure the
> container.
> Using a container with no root mapping is apparently rare, but we do use
> this configuration at Google. Also, we use a generic tool to configure
> the container limits, and the inability to write any of them causes a
> failure.
>
> History
> ===
> The invalid uids/gids in inodes first appeared due to 81754357770e (fs:
> Update i_[ug]id_(read|write) to translate relative to s_user_ns).
> However, AFAIK, this did not immediately cause any issues.
> The inability to write to these "invalid" inodes was only caused by a
> later commit 0bd23d09b874 (vfs: Don't modify inodes with a uid or gid
> unknown to the vfs).
>
> Tested: Used a repro program that creates a user namespace without any
> mapping and stat'ed /proc/$PID/root/proc/sys/kernel/shmmax from outside.
> Before the change, it shows the overflow uid, with the change it's 0.
> The overflow uid indicates that the uid in the inode is not correct and
> thus it is not possible to open the file for writing.
>
> Fixes: 0bd23d09b874 ("vfs: Don't modify inodes with a uid or gid unknown to
> the vfs")
> Cc: sta...@vger.kernel.org # v4.8+
> Signed-off-by: Radoslaw Burny
Acked-by: Luis Chamberlain
Andrew,
When you get a chance, can you pick this one up on your tree? This was
an old patch that just fell through the cracks, but fortuntely Radoslaw
followed through with an updated commit message. This affects only a
small crowd, however it is a proper fix.
Luis
> ---
> Changelog since v1:
> - Updated the commit title and description.
>
> fs/proc/proc_sysctl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index c74570736b24..36ad1b0d6259 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -499,6 +499,10 @@ static struct inode *proc_sys_make_inode(struct
> super_block *sb,
>
> if (root->set_ownership)
> root->set_ownership(head, table, >i_uid, >i_gid);
> + else {
> + inode->i_uid = GLOBAL_ROOT_UID;
> + inode->i_gid = GLOBAL_ROOT_GID;
> + }
>
> return inode;
> }
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
Re: [PATCH v4 1/5] dt-bindings: interconnect: Add Qualcomm QCS404 DT bindings
On Thu 13 Jun 08:13 PDT 2019, Georgi Djakov wrote:
> The Qualcomm QCS404 platform has several buses that could be controlled
> and tuned according to the bandwidth demand.
>
> Reviewed-by: Bjorn Andersson
> Signed-off-by: Georgi Djakov
> ---
>
> v4:
> - Add the DT header into this patch.
> - Pick Bjorn's r-b.
>
> v3:
> - Add a reg property and move the interconnect nodes under the "soc" node.
>
> v2:
> - No changes.
>
> .../bindings/interconnect/qcom,qcs404.txt | 46 ++
> .../dt-bindings/interconnect/qcom,qcs404.h| 88 +++
> 2 files changed, 134 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> create mode 100644 include/dt-bindings/interconnect/qcom,qcs404.h
>
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> new file mode 100644
> index ..14a827268dda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.txt
> @@ -0,0 +1,46 @@
> +Qualcomm QCS404 Network-On-Chip interconnect driver binding
> +---
> +
> +Required properties :
> +- compatible : shall contain only one of the following:
> + "qcom,qcs404-bimc"
> + "qcom,qcs404-pcnoc"
> + "qcom,qcs404-snoc"
> +- #interconnect-cells : should contain 1
> +
> +Optional properties :
> +reg : specifies the physical base address and size of registers
> +clocks : list of phandles and specifiers to all interconnect bus clocks
> +clock-names : clock names should include both "bus_clk" and "bus_a_clk"
Spoke to Rob about this patch, and I don't think these properties should
not be described as optional.
The reg isn't used unless we're implementing support for QoS, but let's
include them in the binding as required anyways.
Iirc the two clocks are required with the current implementation, but
shouldn't there be an iface clock as well, for accessing the QoS
register space?
PS. As I read this again, please drop _clk from the two clocks names -
we know they are clocks...
Regards,
Bjorn
> +
> +Example:
> +
> +soc {
> + ...
> + bimc: interconnect@40 {
> + reg = <0x0040 0x8>;
> + compatible = "qcom,qcs404-bimc";
> + #interconnect-cells = <1>;
> + clock-names = "bus_clk", "bus_a_clk";
> + clocks = < RPM_SMD_BIMC_CLK>,
> + < RPM_SMD_BIMC_A_CLK>;
> + };
> +
> + pnoc: interconnect@50 {
> + reg = <0x0050 0x15080>;
> + compatible = "qcom,qcs404-pcnoc";
> + #interconnect-cells = <1>;
> + clock-names = "bus_clk", "bus_a_clk";
> + clocks = < RPM_SMD_PNOC_CLK>,
> + < RPM_SMD_PNOC_A_CLK>;
> + };
> +
> + snoc: interconnect@58 {
> + reg = <0x0058 0x23080>;
> + compatible = "qcom,qcs404-snoc";
> + #interconnect-cells = <1>;
> + clock-names = "bus_clk", "bus_a_clk";
> + clocks = < RPM_SMD_SNOC_CLK>,
> + < RPM_SMD_SNOC_A_CLK>;
> + };
> +};
> diff --git a/include/dt-bindings/interconnect/qcom,qcs404.h
> b/include/dt-bindings/interconnect/qcom,qcs404.h
> new file mode 100644
> index ..960f6e39c5f2
> --- /dev/null
> +++ b/include/dt-bindings/interconnect/qcom,qcs404.h
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Qualcomm interconnect IDs
> + *
> + * Copyright (c) 2019, Linaro Ltd.
> + * Author: Georgi Djakov
> + */
> +
> +#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_QCS404_H
> +#define __DT_BINDINGS_INTERCONNECT_QCOM_QCS404_H
> +
> +#define MASTER_AMPSS_M0 0
> +#define MASTER_OXILI 1
> +#define MASTER_MDP_PORT0 2
> +#define MASTER_SNOC_BIMC_1 3
> +#define MASTER_TCU_0 4
> +#define SLAVE_EBI_CH05
> +#define SLAVE_BIMC_SNOC 6
> +
> +#define MASTER_SPDM 0
> +#define MASTER_BLSP_11
> +#define MASTER_BLSP_22
> +#define MASTER_XI_USB_HS13
> +#define MASTER_CRYPT04
> +#define MASTER_SDCC_15
> +#define MASTER_SDCC_26
> +#define MASTER_SNOC_PCNOC7
> +#define MASTER_QPIC 8
> +#define PCNOC_INT_0 9
> +#define PCNOC_INT_2 10
> +#define PCNOC_INT_3 11
> +#define PCNOC_S_012
> +#define PCNOC_S_113
> +#define PCNOC_S_214
> +#define PCNOC_S_315
> +#define PCNOC_S_416
> +#define PCNOC_S_617
> +#define PCNOC_S_718
> +#define PCNOC_S_819
Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
Mon, Jul 08, 2019 at 07:27:29PM CEST, mkube...@suse.cz wrote: >On Wed, Jul 03, 2019 at 10:41:51AM +0200, Jiri Pirko wrote: >> Tue, Jul 02, 2019 at 04:52:41PM CEST, mkube...@suse.cz wrote: >> >On Tue, Jul 02, 2019 at 02:25:21PM +0200, Jiri Pirko wrote: >> >> Tue, Jul 02, 2019 at 01:49:59PM CEST, mkube...@suse.cz wrote: >> >> >+ >> >> >+ETHTOOL_A_HEADER_DEV_INDEX (u32) device ifindex >> >> >+ETHTOOL_A_HEADER_DEV_NAME (string)device name >> >> >+ETHTOOL_A_HEADER_INFOMASK (u32) info mask >> >> >+ETHTOOL_A_HEADER_GFLAGS (u32) flags common for all >> >> >requests >> >> >+ETHTOOL_A_HEADER_RFLAGS (u32) request specific flags >> >> >+ >> >> >+ETHTOOL_A_HEADER_DEV_INDEX and ETHTOOL_A_HEADER_DEV_NAME identify the >> >> >device >> >> >+message relates to. One of them is sufficient in requests, if both are >> >> >used, >> >> >+they must identify the same device. Some requests, e.g. global string >> >> >sets, do >> >> >+not require device identification. Most GET requests also allow dump >> >> >requests >> >> >+without device identification to query the same information for all >> >> >devices >> >> >+providing it (each device in a separate message). >> >> >+ >> >> >+Optional info mask allows to ask only for a part of data provided by GET >> >> >> >> How this "infomask" works? What are the bits related to? Is that request >> >> specific? >> > >> >The interpretation is request specific, the information returned for >> >a GET request is divided into multiple parts and client can choose to >> >request one of them (usually one). In the code so far, infomask bits >> >correspond to top level (nest) attributes but I would rather not make it >> >a strict rule. >> >> Wait, so it is a matter of verbosity? If you have multiple parts and the >> user is able to chose one of them, why don't you rather have multiple >> get commands, one per bit. This infomask construct seems redundant to me. > >I thought it was a matter of verbosity because it is a very basic >element of the design, it was even advertised in the cover letter among >the basic ideas, it has been there since the very beginning and in five >previous versions through year and a half, noone did question it. That's >why I thought you objected against unclear description, not against the >concept as such. > >There are two reasons for this design. First is to reduce the number of >requests needed to get the information. This is not so much a problem of >ethtool itself; the only existing commands that would result in multiple >request messages would be "ethtool " and "ethtool -s ". Maybe >also "ethtool -x/-X " but even if the indirection table and hash >key have different bits assigned now, they don't have to be split even >if we split other commands. It may be bigger problem for daemons wanting >to keep track of system configuration which would have to issue many >requests whenever a new device appears. > >Second reason is that with 8-bit genetlink command/message id, the space >is not as infinite as it might seem. I counted quickly, right now the >full series uses 14 ids for kernel messages, with split you propose it >would most likely grow to 44. For full implementation of all ethtool >functionality, we could get to ~60 ids. It's still only 1/4 of the >available space but it's not clear what the future development will look >like. We would certainly need to be careful not to start allocating new >commands for single parameters and try to be foreseeing about what can >be grouped together. But we will need to do that in any case. > >On kernel side, splitting existing messages would make some things a bit >easier. It would also reduce the number of scenarios where only part of >requested information is available or only part of a SET request fails. Okay, I got your point. So why don't we look at if from the other angle. Why don't we have only single get/set command that would be in general used to get/set ALL info from/to the kernel. Where we can have these bits (perhaps rather varlen bitfield) to for user to indicate which data is he interested in? This scales. The other commands would be just for action. Something like RTM_GETLINK/RTM_SETLINK. Makes sense? > >Michal
[PATCH v3 1/7] dt-bindings: net: Add bindings for Realtek PHYs
Add the 'realtek,eee-led-mode-disable' property to disable EEE
LED mode on Realtek PHYs that support it.
Signed-off-by: Matthias Kaehlcke
---
TODO: adapt PHY core to deal with optional compatible strings
Changes in v3:
- added entry for compatible string
- added compatible string to example
- mention that the new property is only available for RTL8211E
Changes in v2:
- document 'realtek,eee-led-mode-disable' instead of
'realtek,enable-ssc' in the initial version
---
.../devicetree/bindings/net/realtek.txt | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/realtek.txt
diff --git a/Documentation/devicetree/bindings/net/realtek.txt
b/Documentation/devicetree/bindings/net/realtek.txt
new file mode 100644
index ..db0333f23fec
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -0,0 +1,31 @@
+Realtek PHY properties.
+
+This document describes properties of Realtek PHYs.
+
+Optional properties:
+- compatible: should be one of the following:
+ "realtek,rtl8201cp", "realtek,rtl8201f", "realtek,rtl8211",
+ "realtek,rtl8211b", "realtek,rtl8211c", "realtek,rtl8211dn",
+ "realtek,rtl8211e", "realtek,rtl8211f", "rtl8366rb"
+
+ the property is required if any of the properties are specified that
+ are only supported for certain Realtek PHYs.
+
+- realtek,eee-led-mode-disable: Disable EEE LED mode on this port.
+
+ Only supported for "realtek,rtl8211e".
+
+
+Example:
+
+mdio0 {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy@1 {
+ compatible = "realtek,rtl8211e";
+ reg = <1>;
+ realtek,eee-led-mode-disable;
+ };
+};
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 0/7] net: phy: realtek: Enable configuration of RTL8211E LEDs and SSC
The Realtek RTL8211E allows customization of the PHY LED behavior, like which LEDs are on for certain link speeds and which LEDs blink when there is traffic. By default EEE LED mode is enabled, in which a blinking LED is on for 400ms and off for 2s. This series adds support for configuring the LED behavior through device tree properties. The RTL8211E supports Spread Spectrum Clocking (SSC), which reduces clock noise that may affect other board functions. By default SSC is disabled, this series adds support for enabling it through a device tree property. Certain registers on the RTL8211E can only be accessed through a vendor specific extended page mechanism. Extended pages need to be accessed for the LED configuration and enabling SSC. This series adds helpers to facilitate accessing extended pages. Matthias Kaehlcke (7): dt-bindings: net: Add bindings for Realtek PHYs net: phy: realtek: Allow disabling RTL8211E EEE LED mode dt-bindings: net: realtek: Add property to enable SSC net: phy: realtek: Add helpers for accessing RTL8211E extension pages net: phy: realtek: Support SSC for the RTL8211E dt-bindings: net: realtek: Add property to configure LED mode net: phy: realtek: configure RTL8211E LEDs .../devicetree/bindings/net/realtek.txt | 47 + drivers/net/phy/realtek.c | 171 -- include/dt-bindings/net/realtek.h | 18 ++ 3 files changed, 221 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/realtek.txt create mode 100644 include/dt-bindings/net/realtek.h -- 2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 2/7] net: phy: realtek: Allow disabling RTL8211E EEE LED mode
EEE LED mode is enabled by default on the RTL8211E. Disable it when
the device tree property 'realtek,eee-led-mode-disable' exists.
The magic values to disable EEE LED mode were taken from the RTL8211E
datasheet, unfortunately they are not further documented.
Signed-off-by: Matthias Kaehlcke
---
TODO: DT validation
Changes in v3:
- don't have two versions of rtl8211e_config_init()
(was due to my dev kernel being 4.19, which doesn't have
this function yet)
- changed return type of rtl8211e_disable_eee_led_mode() to void
- added empty line after rtl8211e_config_init()
Changes in v2:
- patch added to the series
---
drivers/net/phy/realtek.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index a669945eb829..827ea7ed080d 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,8 +9,9 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include
-#include
#include
+#include
+#include
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX BIT(13)
@@ -26,6 +27,10 @@
#define RTL821x_EXT_PAGE_SELECT0x1e
#define RTL821x_PAGE_SELECT0x1f
+/* RTL8211E page 5 */
+#define RTL8211E_EEE_LED_MODE1 0x05
+#define RTL8211E_EEE_LED_MODE2 0x06
+
#define RTL8211F_INSR 0x1d
#define RTL8211F_TX_DELAY BIT(8)
@@ -53,6 +58,26 @@ static int rtl821x_write_page(struct phy_device *phydev, int
page)
return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
}
+static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
+{
+ int oldpage;
+ int err = 0;
+
+ oldpage = phy_select_page(phydev, 5);
+ if (oldpage < 0)
+ goto out;
+
+ /* write magic values to disable EEE LED mode */
+ err = __phy_write(phydev, RTL8211E_EEE_LED_MODE1, 0x8b82);
+ if (err)
+ goto out;
+
+ err = __phy_write(phydev, RTL8211E_EEE_LED_MODE2, 0x052b);
+
+out:
+ phy_restore_page(phydev, oldpage, err);
+}
+
static int rtl8201_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -184,9 +209,13 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
+ struct device *dev = >mdio.dev;
int ret = 0, oldpage;
u16 val;
+ if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
+ rtl8211e_disable_eee_led_mode(phydev);
+
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
case PHY_INTERFACE_MODE_RGMII:
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 3/7] dt-bindings: net: realtek: Add property to enable SSC
Add the 'realtek,enable-ssc' property to enable Spread Spectrum
Clocking (SSC) on Realtek PHYs that support it.
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- changed wording for supported PHY models
Changes in v2:
- patch added to the series (kind of, it already existed, but now
the binding is created by another patch)
---
Documentation/devicetree/bindings/net/realtek.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/realtek.txt
b/Documentation/devicetree/bindings/net/realtek.txt
index db0333f23fec..af2824664f08 100644
--- a/Documentation/devicetree/bindings/net/realtek.txt
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -15,6 +15,10 @@ Optional properties:
Only supported for "realtek,rtl8211e".
+- realtek,enable-ssc : Enable Spread Spectrum Clocking (SSC) on this port.
+
+ Only supported for "realtek,rtl8211e".
+
Example:
@@ -27,5 +31,6 @@ mdio0 {
compatible = "realtek,rtl8211e";
reg = <1>;
realtek,eee-led-mode-disable;
+ realtek,enable-ssc;
};
};
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 5/7] net: phy: realtek: Support SSC for the RTL8211E
By default Spread-Spectrum Clocking (SSC) is disabled on the RTL8211E.
Enable it if the device tree property 'realtek,enable-ssc' exists.
Signed-off-by: Matthias Kaehlcke
---
TODO: DT validation
Changes in v3:
- use phydev_err() instead of dev_err()
Changes in v2:
- enable SSC in config_init() instead of probe()
- fixed error check after enabling SSC
---
drivers/net/phy/realtek.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index fa11ae5ebd91..5854412403b5 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,6 +9,7 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include
+#include
#include
#include
#include
@@ -33,6 +34,10 @@
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
+/* RTL8211E extension page 160 */
+#define RTL8211E_SCR 0x1a
+#define RTL8211E_SCR_DISABLE_RXC_SSC BIT(2)
+
#define RTL8211F_INSR 0x1d
#define RTL8211F_TX_DELAY BIT(8)
@@ -250,8 +255,18 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
struct device *dev = >mdio.dev;
+ int ret;
u16 val;
+ if (of_property_read_bool(dev->of_node, "realtek,enable-ssc")) {
+ ret = rtl8211e_modify_ext_paged(phydev, 0xa0, RTL8211E_SCR,
+ RTL8211E_SCR_DISABLE_RXC_SSC,
+ 0);
+ if (ret < 0)
+ phydev_err(phydev, "failed to enable SSC on RXC: %d\n",
+ ret);
+ }
+
if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
rtl8211e_disable_eee_led_mode(phydev);
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 4/7] net: phy: realtek: Add helpers for accessing RTL8211E extension pages
The RTL8211E has extension pages, which can be accessed after
selecting a page through a custom method. Add a function to
modify bits in a register of an extension page and a helper for
selecting an ext page. Use rtl8211e_modify_ext_paged() in
rtl8211e_config_init() instead of doing things 'manually'.
rtl8211e_modify_ext_paged() is inspired by its counterpart
phy_modify_paged().
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- use the new function in rtl8211e_config_init() instead of
doing things 'manually'
- use existing RTL8211E_EXT_PAGE instead of adding a new define
- updated commit message
Changes in v2:
- use phy_select_page() and phy_restore_page(), get rid of
rtl8211e_restore_page()
- s/rtl821e_select_ext_page/rtl8211e_select_ext_page/
- updated commit message
---
drivers/net/phy/realtek.c | 57 +--
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 827ea7ed080d..fa11ae5ebd91 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -27,6 +27,8 @@
#define RTL821x_EXT_PAGE_SELECT0x1e
#define RTL821x_PAGE_SELECT0x1f
+#define RTL8211E_EXT_PAGE 7
+
/* RTL8211E page 5 */
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
@@ -58,6 +60,44 @@ static int rtl821x_write_page(struct phy_device *phydev, int
page)
return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
}
+static int rtl8211e_select_ext_page(struct phy_device *phydev, int page)
+{
+ int ret, oldpage;
+
+ oldpage = phy_select_page(phydev, RTL8211E_EXT_PAGE);
+ if (oldpage < 0)
+ return oldpage;
+
+ ret = __phy_write(phydev, RTL821x_EXT_PAGE_SELECT, page);
+ if (ret)
+ return phy_restore_page(phydev, page, ret);
+
+ return 0;
+}
+
+static int rtl8211e_modify_ext_paged(struct phy_device *phydev, int page,
+u32 regnum, u16 mask, u16 set)
+{
+ int ret = 0;
+ int oldpage;
+ int new;
+
+ oldpage = rtl8211e_select_ext_page(phydev, page);
+ if (oldpage < 0)
+ goto out;
+
+ ret = __phy_read(phydev, regnum);
+ if (ret < 0)
+ goto out;
+
+ new = (ret & ~mask) | set;
+ if (new != ret)
+ ret = __phy_write(phydev, regnum, new);
+
+out:
+ return phy_restore_page(phydev, oldpage, ret);
+}
+
static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
{
int oldpage;
@@ -210,7 +250,6 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
struct device *dev = >mdio.dev;
- int ret = 0, oldpage;
u16 val;
if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
@@ -242,19 +281,9 @@ static int rtl8211e_config_init(struct phy_device *phydev)
* 2 = RX Delay, 1 = TX Delay, 0 = SELRGV (see original PHY datasheet
* for details).
*/
- oldpage = phy_select_page(phydev, 0x7);
- if (oldpage < 0)
- goto err_restore_page;
-
- ret = __phy_write(phydev, RTL821x_EXT_PAGE_SELECT, 0xa4);
- if (ret)
- goto err_restore_page;
-
- ret = __phy_modify(phydev, 0x1c, RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
- val);
-
-err_restore_page:
- return phy_restore_page(phydev, oldpage, ret);
+ return rtl8211e_modify_ext_paged(phydev, 0xa4, 0x1c,
+RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
+val);
}
static int rtl8211b_suspend(struct phy_device *phydev)
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 6/7] dt-bindings: net: realtek: Add property to configure LED mode
The LED behavior of some Realtek PHYs is configurable. Add the
property 'realtek,led-modes' to specify the configuration of the
LEDs.
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- added RTL8211E_LED_OFF to LED modes
- changed wording for supported PHY models
Changes in v2:
- patch added to the series
---
.../devicetree/bindings/net/realtek.txt| 11 +++
include/dt-bindings/net/realtek.h | 18 ++
2 files changed, 29 insertions(+)
create mode 100644 include/dt-bindings/net/realtek.h
diff --git a/Documentation/devicetree/bindings/net/realtek.txt
b/Documentation/devicetree/bindings/net/realtek.txt
index af2824664f08..ab218f2b7653 100644
--- a/Documentation/devicetree/bindings/net/realtek.txt
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -19,6 +19,14 @@ Optional properties:
Only supported for "realtek,rtl8211e".
+- realtek,led-modes: LED mode configuration.
+
+ A 0..3 element vector, with each element configuring the operating
+ mode of an LED. Omitted LEDs are turned off. Allowed values are
+ defined in "include/dt-bindings/net/realtek.h".
+
+ Only supported for "realtek,rtl8211e".
+
Example:
@@ -32,5 +40,8 @@ mdio0 {
reg = <1>;
realtek,eee-led-mode-disable;
realtek,enable-ssc;
+ realtek,led-modes = ;
};
};
diff --git a/include/dt-bindings/net/realtek.h
b/include/dt-bindings/net/realtek.h
new file mode 100644
index ..023cb776a7a3
--- /dev/null
+++ b/include/dt-bindings/net/realtek.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_REALTEK_H
+#define _DT_BINDINGS_REALTEK_H
+
+/* LED modes for RTL8211E PHY */
+
+#define RTL8211E_LED_OFF 0
+#define RTL8211E_LINK_10 1
+#define RTL8211E_LINK_100 2
+#define RTL8211E_LINK_1000 4
+#define RTL8211E_LINK_10_100 3
+#define RTL8211E_LINK_10_1000 5
+#define RTL8211E_LINK_100_1000 6
+#define RTL8211E_LINK_10_100_1000 7
+
+#define RTL8211E_LINK_ACTIVITY (1 << 16)
+
+#endif
--
2.22.0.410.gd8fdbe21b5-goog
[PATCH v3 7/7] net: phy: realtek: configure RTL8211E LEDs
Configure the RTL8211E LEDs behavior when the device tree property
'realtek,led-modes' is specified.
Signed-off-by: Matthias Kaehlcke
---
TODO: DT validation
Changes in v3:
- sanity check led-modes values
- set LACR bits in a more readable way
- use phydev_err() instead of dev_err()
- log an error if LED configuration fails
Changes in v2:
- patch added to the series
---
drivers/net/phy/realtek.c | 72 +--
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 5854412403b5..e9fb67654c4e 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,10 +9,12 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include
+#include
#include
#include
#include
#include
+#include
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX BIT(13)
@@ -34,6 +36,15 @@
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
+/* RTL8211E extension page 44 */
+#define RTL8211E_LACR 0x1a
+#define RLT8211E_LACR_LEDACTCTRL_SHIFT 4
+#define RLT8211E_LACR_LEDACTCTRL_MASK GENMASK(6, 4)
+#define RTL8211E_LCR 0x1c
+#define RTL8211E_LCR_LEDCTRL_MASK (GENMASK(2, 0) | \
+GENMASK(6, 4) | \
+GENMASK(10, 8))
+
/* RTL8211E extension page 160 */
#define RTL8211E_SCR 0x1a
#define RTL8211E_SCR_DISABLE_RXC_SSC BIT(2)
@@ -123,6 +134,62 @@ static void rtl8211e_disable_eee_led_mode(struct
phy_device *phydev)
phy_restore_page(phydev, oldpage, err);
}
+static int rtl8211e_config_leds(struct phy_device *phydev)
+{
+ struct device *dev = >mdio.dev;
+ int count, i, oldpage, ret;
+ u16 lacr_bits = 0, lcr_bits = 0;
+
+ if (!dev->of_node)
+ return 0;
+
+ if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
+ rtl8211e_disable_eee_led_mode(phydev);
+
+ count = of_property_count_elems_of_size(dev->of_node,
+ "realtek,led-modes",
+ sizeof(u32));
+ if (count < 0 || count > 3)
+ return -EINVAL;
+
+ for (i = 0; i < count; i++) {
+ u32 val;
+
+ of_property_read_u32_index(dev->of_node,
+ "realtek,led-modes", i, );
+ if ((val > RTL8211E_LINK_10_100_1000 &&
+ val < RTL8211E_LINK_ACTIVITY) ||
+ val > (RTL8211E_LINK_ACTIVITY | RTL8211E_LINK_10_100_1000))
+ return -EINVAL;
+
+ if (val & RTL8211E_LINK_ACTIVITY)
+ lacr_bits |= BIT(RLT8211E_LACR_LEDACTCTRL_SHIFT + i);
+
+ lcr_bits |= (u16)(val & 0xf) << (i * 4);
+ }
+
+ oldpage = rtl8211e_select_ext_page(phydev, 44);
+ if (oldpage < 0) {
+ phydev_err(phydev, "failed to select extended page: %d\n",
oldpage);
+ goto err;
+ }
+
+ ret = __phy_modify(phydev, RTL8211E_LACR,
+ RLT8211E_LACR_LEDACTCTRL_MASK, lacr_bits);
+ if (ret) {
+ phydev_err(phydev, "failed to write LACR reg: %d\n", ret);
+ goto err;
+ }
+
+ ret = __phy_modify(phydev, RTL8211E_LCR,
+ RTL8211E_LCR_LEDCTRL_MASK, lcr_bits);
+ if (ret)
+ phydev_err(phydev, "failed to write LCR reg: %d\n", ret);
+
+err:
+ return phy_restore_page(phydev, oldpage, ret);
+}
+
static int rtl8201_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -267,8 +334,9 @@ static int rtl8211e_config_init(struct phy_device *phydev)
ret);
}
- if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
- rtl8211e_disable_eee_led_mode(phydev);
+ ret = rtl8211e_config_leds(phydev);
+ if (ret)
+ phydev_err(phydev, "LED configuration failed: %d\n", ret);
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
--
2.22.0.410.gd8fdbe21b5-goog
Re: [GIT pull] x86/pti for 5.3-rc1
On Mon, Jul 8, 2019 at 2:22 AM Thomas Gleixner wrote:
>
> @@ -643,9 +644,11 @@ static unsigned long ptrace_get_debugreg(struct
> task_struct *tsk, int n)
> {
> struct thread_struct *thread = >thread;
> unsigned long val = 0;
> + int index = n;
>
> if (n < HBP_NUM) {
> - struct perf_event *bp = thread->ptrace_bps[n];
> + index = array_index_nospec(index, HBP_NUM);
> + struct perf_event *bp = thread->ptrace_bps[index];
This causes a new warning:
warning: ISO C90 forbids mixed declarations and code
and I'm fixing it up in the merge as follows:
@@@ -633,9 -644,11 +634,10 @@@ static unsigned long ptrace_get_debugre
{
struct thread_struct *thread = >thread;
unsigned long val = 0;
- int index = n;
if (n < HBP_NUM) {
- struct perf_event *bp = thread->ptrace_bps[n];
- index = array_index_nospec(index, HBP_NUM);
++ int index = array_index_nospec(n, HBP_NUM);
+ struct perf_event *bp = thread->ptrace_bps[index];
if (bp)
val = bp->hw.info.address;
Holler if I did something stupid.
Linus
Re: [PATCH v3] RDMA/core: Fix race when resolving IP address
On 7/8/19 11:47 AM, Dag Moxnes wrote: > Thanks Jason, > > Regards, > Dag > > Den 08.07.2019 19:50, skrev Jason Gunthorpe: >> On Mon, Jul 08, 2019 at 01:16:24PM +0200, Dag Moxnes wrote: >>> Use neighbour lock when copying MAC address from neighbour data struct >>> in dst_fetch_ha. >>> >>> When not using the lock, it is possible for the function to race with >>> neigh_update, causing it to copy an invalid MAC address. >>> >>> It is possible to provoke this error by calling rdma_resolve_addr in a >>> tight loop, while deleting the corresponding ARP entry in another tight >>> loop. >>> >>> This will cause the race shown it the following sample trace: >>> >>> rdma_resolve_addr() >>> rdma_resolve_ip() >>> addr_resolve() >>> addr_resolve_neigh() >>> fetch_ha() >>> dst_fetch_ha() >>> n->nud_state == NUD_VALID >> It isn't nud_state that is the problem here, it is the parallel >> memcpy's onto ha. I fixed the commit message >> >> This could also have been solved by using the ha_lock, but I don't >> think we have a reason to particularly over-optimize this. Sorry I'm late to the party, but why not just use: neigh_ha_snapshot()? >> >>> drivers/infiniband/core/addr.c | 9 ++--- >>> 1 file changed, 6 insertions(+), 3 deletions(-) >> Applied to for-next, thanks >> >> Jason > Mark
Re: [PATCH] selftests/ftrace: Select an existing function in kprobe_eventname test
On Mon, 8 Jul 2019 16:10:29 -0300
Thadeu Lima de Souza Cascardo wrote:
> On Fri, Mar 22, 2019 at 03:09:23PM -0400, Steven Rostedt wrote:
> > From: Steven Rostedt (VMware)
> >
> > Running the ftrace selftests on the latest kernel caused the
> > kprobe_eventname test to fail. It was due to the test that searches for
> > a function with at "dot" in the name and adding a probe to that.
> > Unfortunately, for this test, it picked:
> >
> > optimize_nops.isra.2.cold.4
> >
> > Which happens to be marked as "__init", which means it no longer exists
> > in the kernel! (kallsyms keeps those function names around for tracing
> > purposes)
> >
> > As only functions that still exist are in the
> > available_filter_functions file, as they are removed when the functions
> > are freed at boot or module exit, have the test search for a function
> > with ".isra." in the name as well as being in the
> > available_filter_functions (if the file exists).
> >
>
> This fixes a similar problem for me.
>
> Tested-by: Thadeu Lima de Souza Cascardo
Masami, can you ack this, and Shuah, can you take it?
Thanks!
-- Steve
>
> > Signed-off-by: Steven Rostedt (VMware)
> > ---
> > diff --git
> > a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > index 3fb70e01b1fe..3ff236719b6e 100644
> > --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> > @@ -24,7 +24,21 @@ test -d events/kprobes2/event2 || exit_failure
> >
> > :;: "Add an event on dot function without name" ;:
> >
> > -FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f
> > 3 -d " "`
> > +find_dot_func() {
> > + if [ ! -f available_filter_functions ]; then
> > + grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 |
> > cut -f 3 -d " "
> > + return;
> > + fi
> > +
> > + grep " [tT] .*\.isra\..*" /proc/kallsyms | cut -f 3 -d " " | while read
> > f; do
> > + if grep -s $f available_filter_functions; then
> > + echo $f
> > + break
> > + fi
> > + done
> > +}
> > +
> > +FUNC=`find_dot_func | tail -n 1`
> > [ "x" != "x$FUNC" ] || exit_unresolved
> > echo "p $FUNC" > kprobe_events
> > EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:`
Re: linux-next: Tree for Jul 8 --> bootup failure on s390x (bisected)
On 08.07.19 20:06, Al Viro wrote:
> On Mon, Jul 08, 2019 at 06:52:14PM +0200, Christian Borntraeger wrote:
>
>> smp: Brought up 1 node, 1 CPU
>> Unable to handle kernel pointer dereference in virtual kernel address space
>> Failing address: 3a07 TEID: 3a070407
>> Fault in home space mode while using kernel ASCE.
>> AS:3a780007 R3:7ffd0007 S:7ffd4800
>> P:3a07021d
>> Oops: 0004 ilc:2 [#1] SMP
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5-00101-gcb8f0b366109 #14
>> Hardware name: IBM 2964 NC9 712 (KVM/Linux)
>> Krnl PSW : 0704e0018000 3974b580
>> (shmem_parse_monolithic+0x88/0x100)
>>R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
>> Krnl GPRS: 003d 3a07040e
>> 003d
>>3a07040f 006d 0001
>>
>>7f7c1c00 3a07040a
>>
>>7f7e4000 3a190d78 3974b56c
>> 03e00031fd38
>> Krnl Code: 3974b574: b920002acgr %r2,%r10
>>3974b578: a784001bbrc 8,3974b5ae
>> #3974b57c: 41402001la %r4,1(%r2)
>> >3974b580: 92002000mvi 0(%r2),0
>>3974b584: a709lghi%r0,0
>>3974b588: b9040014lgr %r1,%r4
>>3974b58c: b25e0001srst%r0,%r1
>>3974b590: a714fffebrc 1,3974b58c
>> Call Trace:
>> ([<03e00031fd80>] 0x3e00031fd80)
>> [<39811662>] vfs_kern_mount.part.0+0x9a/0xc8
>> [<3a302fc0>] devtmpfs_init+0x38/0x140
>> [<3a302e0a>] driver_init+0x22/0x60
>> [<3a2beff8>] kernel_init_freeable+0x298/0x4f0
>> [<39e7b53a>] kernel_init+0x22/0x148
>> [<39e87b70>] ret_from_fork+0x30/0x34
>> [<39e87b74>] kernel_thread_starter+0x0/0xc
>> INFO: lockdep is turned off.
>> [...]
>
> Oh, fuck... OK, I understand what's going on; sorry, my fault. Could you
> verify that the following helps?
Yes, it does.
>
> diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
> index 52312c665a38..30d0523014e0 100644
> --- a/drivers/base/devtmpfs.c
> +++ b/drivers/base/devtmpfs.c
> @@ -431,9 +431,10 @@ static int devtmpfsd(void *p)
> */
> int __init devtmpfs_init(void)
> {
> + char opts[] = "mode=0755";
> int err;
>
> - mnt = vfs_kern_mount(_fs_type, 0, "devtmpfs", "mode=0755");
> + mnt = vfs_kern_mount(_fs_type, 0, "devtmpfs", opts);
> if (IS_ERR(mnt)) {
> printk(KERN_ERR "devtmpfs: unable to create devtmpfs %ld\n",
> PTR_ERR(mnt));
>
Re: [PATCH v2] powerpc: slightly improve cache helpers
On Mon, Jul 08, 2019 at 11:19:30AM +1000, Michael Ellerman wrote: > On Fri, 2019-05-10 at 09:24:48 UTC, Christophe Leroy wrote: > > Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers > > that are summed to obtain the target address. Using 'Z' constraint > > and '%y0' argument gives GCC the opportunity to use both registers > > instead of only one with the second being forced to 0. > > > > Suggested-by: Segher Boessenkool > > Signed-off-by: Christophe Leroy > > Applied to powerpc next, thanks. > > https://git.kernel.org/powerpc/c/6c5875843b87c3adea2beade9d1b8b3d4523900a > > cheers This patch causes a regression with clang: https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/213944668 I've attached my local bisect/build log. Cheers, Nathan git bisect start # good: [46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28] Merge tag 'for-linus-20190706' of git://git.kernel.dk/linux-block git bisect good 46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28 # bad: [d58b5ab90ee7528126fd5833df7fc5bda8331ce8] Add linux-next specific files for 20190708 git bisect bad d58b5ab90ee7528126fd5833df7fc5bda8331ce8 # bad: [ba30fb6d5d6464bd7d3759408ea7f178d8c9fe87] Merge remote-tracking branch 'crypto/master' git bisect bad ba30fb6d5d6464bd7d3759408ea7f178d8c9fe87 # bad: [eaa0d0d3b269695df5d682d3dfcfb5c6e8f19fa8] Merge remote-tracking branch 'i3c/i3c/next' git bisect bad eaa0d0d3b269695df5d682d3dfcfb5c6e8f19fa8 # good: [e41aad4a290783ec7d3730542cbed0e99b2dcb4a] Merge remote-tracking branch 'tegra/for-next' git bisect good e41aad4a290783ec7d3730542cbed0e99b2dcb4a # bad: [c5a28b5f954e769decf4b69c06ecfd27ebeaeb5b] Merge remote-tracking branch 'cifs/for-next' git bisect bad c5a28b5f954e769decf4b69c06ecfd27ebeaeb5b # bad: [8e8fefda572360f00854547f3458a9c2cf932ff5] Merge remote-tracking branch 'powerpc/next' git bisect bad 8e8fefda572360f00854547f3458a9c2cf932ff5 # good: [01fd0e565283d69adf0ff1da95cab5bb4cb58acb] Merge remote-tracking branch 'm68k/for-next' git bisect good 01fd0e565283d69adf0ff1da95cab5bb4cb58acb # good: [7505a13f85bdcb8713551a067dfc92ac3c7ba902] powerpc/configs: Disable latencytop git bisect good 7505a13f85bdcb8713551a067dfc92ac3c7ba902 # good: [958ace9b9edae56953190fdbdddc55d6506ec6f7] Merge remote-tracking branch 'nios2/for-next' git bisect good 958ace9b9edae56953190fdbdddc55d6506ec6f7 # bad: [1cfb725fb1899dc6fdc88f8b5354a65e8ad260c6] powerpc/64: flush_inval_dcache_range() becomes flush_dcache_range() git bisect bad 1cfb725fb1899dc6fdc88f8b5354a65e8ad260c6 # good: [89a3496e0664577043666791ec07fb731d57c950] powerpc/mm/radix: Use the right page size for vmemmap mapping git bisect good 89a3496e0664577043666791ec07fb731d57c950 # good: [259a948c4ba1829ae4a3c31bb6e40ad458a21254] powerpc/pseries/scm: Use a specific endian format for storing uuid from the device tree git bisect good 259a948c4ba1829ae4a3c31bb6e40ad458a21254 # good: [2230ebf6e6dd0b7751e2921b40f6cfe34f09bb16] powerpc/mm: Handle page table allocation failures git bisect good 2230ebf6e6dd0b7751e2921b40f6cfe34f09bb16 # good: [ac25ba68fa4001c85395f0488b1c7a2421c5aada] powerpc/mm/hugetlb: Don't enable HugeTLB if we don't have a page table cache git bisect good ac25ba68fa4001c85395f0488b1c7a2421c5aada # bad: [6c5875843b87c3adea2beade9d1b8b3d4523900a] powerpc: slightly improve cache helpers git bisect bad 6c5875843b87c3adea2beade9d1b8b3d4523900a # first bad commit: [6c5875843b87c3adea2beade9d1b8b3d4523900a] powerpc: slightly improve cache helpers make[1]: Entering directory '/mnt/build/kernel' CLEAN . CLEAN arch/powerpc/kernel/vdso32 CLEAN arch/powerpc/kernel CLEAN lib CLEAN drivers/scsi CLEAN usr CLEAN scripts/basic CLEAN scripts/dtc rm -f .tmp_symbols.txt CLEAN scripts/mod CLEAN scripts/kconfig CLEAN scripts CLEAN arch/powerpc/boot CLEAN .tmp_versions CLEAN modules.builtin.modinfo CLEAN include/config include/generated arch/powerpc/include/generated CLEAN .config .config.old .version Module.symvers HOSTCC scripts/basic/fixdep GEN Makefile HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o LEX scripts/kconfig/lexer.lex.c YACCscripts/kconfig/parser.tab.h YACCscripts/kconfig/parser.tab.c HOSTCC scripts/kconfig/expr.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/lexer.lex.o HOSTLD scripts/kconfig/conf # # configuration written to .config # SYSTBL arch/powerpc/include/generated/asm/syscall_table_64.h SYSTBL arch/powerpc/include/generated/asm/syscall_table_c32.h SYSTBL arch/powerpc/include/generated/asm/syscall_table_32.h SYSTBL arch/powerpc/include/generated/asm/syscall_table_spu.h SYSHDR arch/powerpc/include/generated/uapi/asm/unistd_64.h SYSHDR arch/powerpc/include/generated/uapi/asm/unistd_32.h GEN Makefile WRAParch/powerpc/i
Re: [PATCH 3/9] security: Add a hook for the point of notification insertion [ver #5]
On 6/28/19 11:49 AM, David Howells wrote:
Add a security hook that allows an LSM to rule on whether a notification
message is allowed to be inserted into a particular watch queue.
The hook is given the following information:
(1) The credentials of the triggerer (which may be init_cred for a system
notification, eg. a hardware error).
(2) The credentials of the whoever set the watch.
(3) The notification message.
As with the other proposed hooks, it is difficult to evaluate this hook
without at least one implementation of the hook. Since Casey is the
only one requesting this hook, a Smack implementation would be the
natural choice; I do not intend to implement this hook for SELinux.
However, by providing this hook, you are in effect taking a position wrt
the earlier controversy over it, i.e. that application developers must
deal with the possibility that notifications can be dropped if a
security module does not permit the triggerer to post the notification
to the watcher, without any indication to either the triggerer or the
watcher. This is a choice you are making by providing this hook. The
alternative is to require that permission to set a watch imply the
ability to receive all notifications for the watched object. Aside from
friendliness to application developers, the latter also yields stable,
sane policy and better performance.
Signed-off-by: David Howells
cc: Casey Schaufler
cc: Stephen Smalley
cc: linux-security-mod...@vger.kernel.org
---
include/linux/lsm_hooks.h | 10 ++
include/linux/security.h | 10 ++
security/security.c |6 ++
3 files changed, 26 insertions(+)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index f9d31f6445e4..fd4b2b14e7d0 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1426,6 +1426,12 @@
*from devices (as a global set).
*@watch: The watch object
*
+ * @post_notification:
+ * Check to see if a watch notification can be posted to a particular
+ * queue.
+ * @w_cred: The credentials of the whoever set the watch.
+ * @cred: The event-triggerer's credentials
+ * @n: The notification being posted
*
* Security hooks for using the eBPF maps and programs functionalities through
* eBPF syscalls.
@@ -1705,6 +1711,9 @@ union security_list_options {
#ifdef CONFIG_WATCH_QUEUE
int (*watch_key)(struct watch *watch, struct key *key);
int (*watch_devices)(struct watch *watch);
+ int (*post_notification)(const struct cred *w_cred,
+const struct cred *cred,
+struct watch_notification *n);
#endif /* CONFIG_WATCH_QUEUE */
#ifdef CONFIG_SECURITY_NETWORK
@@ -1985,6 +1994,7 @@ struct security_hook_heads {
#ifdef CONFIG_WATCH_QUEUE
struct hlist_head watch_key;
struct hlist_head watch_devices;
+ struct hlist_head post_notification;
#endif /* CONFIG_WATCH_QUEUE */
#ifdef CONFIG_SECURITY_NETWORK
struct hlist_head unix_stream_connect;
diff --git a/include/linux/security.h b/include/linux/security.h
index 540863678355..5c074bf18bea 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -58,6 +58,7 @@ struct fs_context;
struct fs_parameter;
enum fs_value_type;
struct watch;
+struct watch_notification;
/* Default (no) options for the capable function */
#define CAP_OPT_NONE 0x0
@@ -396,6 +397,9 @@ int security_inode_getsecctx(struct inode *inode, void
**ctx, u32 *ctxlen);
#ifdef CONFIG_WATCH_QUEUE
int security_watch_key(struct watch *watch, struct key *key);
int security_watch_devices(struct watch *watch);
+int security_post_notification(const struct cred *w_cred,
+ const struct cred *cred,
+ struct watch_notification *n);
#endif /* CONFIG_WATCH_QUEUE */
#else /* CONFIG_SECURITY */
@@ -1218,6 +1222,12 @@ static inline int security_watch_devices(struct watch *watch)
{
return 0;
}
+static inline int security_post_notification(const struct cred *w_cred,
+const struct cred *cred,
+struct watch_notification *n)
+{
+ return 0;
+}
#endif /* CONFIG_WATCH_QUEUE */
#endif/* CONFIG_SECURITY */
diff --git a/security/security.c b/security/security.c
index 2c9919226ad1..459e87d55ac9 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1928,6 +1928,12 @@ int security_watch_devices(struct watch *watch)
return call_int_hook(watch_devices, 0, watch);
}
+int security_post_notification(const struct cred *w_cred,
+ const struct cred *cred,
+ struct watch_notification *n)
+{
+ return call_int_hook(post_notification, 0, w_cred, cred, n);
+}
#endif /* CONFIG_WATCH_QUEUE */
#ifdef CONFIG_SECURITY_NETWORK
Re: m68k build failures in -next: undefined reference to `arch_dma_prep_coherent'
Hi Günter,
On Mon, Jul 8, 2019 at 7:06 PM Guenter Roeck wrote:
> I see the following build error in -next:
>
> kernel/dma/direct.o: In function `dma_direct_alloc_pages':
> direct.c:(.text+0x4d8): undefined reference to `arch_dma_prep_coherent'
>
> Example: m68k:allnoconfig.
>
> Bisect log is ambiguous and points to the merge of m68k/for-next into
> -next. Yet, I think the problem is with commit 69878ef47562 ("m68k:
> Implement arch_dma_prep_coherent()") which is supposed to introduce
> the function. The problem is likely that arch_dma_prep_coherent()
> is only declared if CONFIG_MMU is enabled, but it is called from code
> outside CONFIG_MMU.
Thanks, one more thing to fix in m68k-allnoconfig (did it really build
before?)...
Given you say "example", does it fail in real configs, too?
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 4.9 000/102] 4.9.185-stable review
stable-rc/linux-4.9.y boot: 94 boots: 2 failed, 92 passed (v4.9.184-102-gf075c4e9d730) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.184-102-gf075c4e9d730/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.184-102-gf075c4e9d730/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.184-102-gf075c4e9d730 Git Commit: f075c4e9d7301b229ebc16b6ae51dd5094802c48 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 49 unique boards, 21 SoC families, 15 builds out of 197 Boot Failures Detected: arm: sunxi_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab multi_v7_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab --- For more info write to
Re: [PATCH 5.1 00/96] 5.1.17-stable review
stable-rc/linux-5.1.y boot: 108 boots: 3 failed, 105 passed (v5.1.16-96-gadc3bfb5810c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.1.y/kernel/v5.1.16-96-gadc3bfb5810c/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.1.y/kernel/v5.1.16-96-gadc3bfb5810c/ Tree: stable-rc Branch: linux-5.1.y Git Describe: v5.1.16-96-gadc3bfb5810c Git Commit: adc3bfb5810c7d89758b29f1736fc927757ea64f Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 24 SoC families, 15 builds out of 209 Boot Failures Detected: arm: sunxi_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab multi_v7_defconfig: gcc-8: bcm4708-smartrg-sr400ac: 1 failed lab sun7i-a20-bananapi: 1 failed lab --- For more info write to
Re: [PATCH 4.4 00/73] 4.4.185-stable review
stable-rc/linux-4.4.y boot: 100 boots: 4 failed, 95 passed with 1 conflict (v4.4.184-73-g71b130d46805) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.184-73-g71b130d46805/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.184-73-g71b130d46805/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.184-73-g71b130d46805 Git Commit: 71b130d468055291345db697052e5256d6e46397 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 46 unique boards, 20 SoC families, 14 builds out of 190 Boot Failures Detected: arm: sunxi_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab multi_v7_defconfig: gcc-8: stih410-b2120: 1 failed lab sun7i-a20-bananapi: 1 failed lab arm64: defconfig: gcc-8: qcom-qdf2400: 1 failed lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu: lab-drue: PASS (gcc-8) lab-baylibre: FAIL (gcc-8) lab-mhart: PASS (gcc-8) lab-collabora: PASS (gcc-8) lab-linaro-lkft: PASS (gcc-8) --- For more info write to
Re: [PATCH 4.19 00/90] 4.19.58-stable review
stable-rc/linux-4.19.y boot: 100 boots: 2 failed, 98 passed (v4.19.57-91-g7b63e70b83fc) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.57-91-g7b63e70b83fc/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.57-91-g7b63e70b83fc/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.57-91-g7b63e70b83fc Git Commit: 7b63e70b83fca977d86fe50ca2a48f40addac0a4 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 60 unique boards, 24 SoC families, 15 builds out of 206 Boot Failures Detected: arm: sunxi_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab multi_v7_defconfig: gcc-8: sun7i-a20-bananapi: 1 failed lab --- For more info write to
Re: [PATCH] selftests/ftrace: Select an existing function in kprobe_eventname test
On Fri, Mar 22, 2019 at 03:09:23PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> Running the ftrace selftests on the latest kernel caused the
> kprobe_eventname test to fail. It was due to the test that searches for
> a function with at "dot" in the name and adding a probe to that.
> Unfortunately, for this test, it picked:
>
> optimize_nops.isra.2.cold.4
>
> Which happens to be marked as "__init", which means it no longer exists
> in the kernel! (kallsyms keeps those function names around for tracing
> purposes)
>
> As only functions that still exist are in the
> available_filter_functions file, as they are removed when the functions
> are freed at boot or module exit, have the test search for a function
> with ".isra." in the name as well as being in the
> available_filter_functions (if the file exists).
>
This fixes a similar problem for me.
Tested-by: Thadeu Lima de Souza Cascardo
> Signed-off-by: Steven Rostedt (VMware)
> ---
> diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> index 3fb70e01b1fe..3ff236719b6e 100644
> --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
> @@ -24,7 +24,21 @@ test -d events/kprobes2/event2 || exit_failure
>
> :;: "Add an event on dot function without name" ;:
>
> -FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3
> -d " "`
> +find_dot_func() {
> + if [ ! -f available_filter_functions ]; then
> + grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 |
> cut -f 3 -d " "
> + return;
> + fi
> +
> + grep " [tT] .*\.isra\..*" /proc/kallsyms | cut -f 3 -d " " | while read
> f; do
> + if grep -s $f available_filter_functions; then
> + echo $f
> + break
> + fi
> + done
> +}
> +
> +FUNC=`find_dot_func | tail -n 1`
> [ "x" != "x$FUNC" ] || exit_unresolved
> echo "p $FUNC" > kprobe_events
> EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:`
Re: [PATCH v8 06/11] x86/CPU: Adapt assembly for PIE support
Thomas Garnier wrote: > - "pushq $1f\n\t" > + "movabsq $1f, %q0\n\t" > + "pushq %q0\n\t" > "iretq\n\t" > UNWIND_HINT_RESTORE > "1:" Fake PIE. True PIE looks like this: 81022d70 : 81022d70: 8c d0 moveax,ss 81022d72: 50 push rax 81022d73: 54 push rsp 81022d74: 48 83 04 24 08 addQWORD PTR [rsp],0x8 81022d79: 9c pushf 81022d7a: 8c c8 moveax,cs 81022d7c: 50 push rax 81022d7d: ===> 48 8d 05 03 00 00 00learax,[rip+0x3]# 81022d87 81022d84: 50 push rax 81022d85: 48 cf iretq 81022d87: c3 ret Signed-off-by: Alexey Dobriyan --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -710,7 +710,8 @@ static inline void sync_core(void) "pushfq\n\t" "mov %%cs, %0\n\t" "pushq %q0\n\t" - "pushq $1f\n\t" + "leaq 1f(%%rip), %q0\n\t" + "pushq %q0\n\t" "iretq\n\t" UNWIND_HINT_RESTORE "1:"
Re: [PATCH 4.14 00/56] 4.14.133-stable review
On Mon, Jul 08, 2019 at 05:12:52PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.133 release. > There are 56 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 know. > > Responses should be made by Wed 10 Jul 2019 03:03:52 PM UTC. > Anything received after that time might be too late. Hi Greg, Compiled and booted on my x86_64 system. Thanks, - Luke
Re: [PATCH] blk-throttle: fix zero wait time for iops throttled group
On Mon, Jul 08, 2019 at 06:29:57PM +0300, Konstantin Khlebnikov wrote:
> After commit 991f61fe7e1d ("Blk-throttle: reduce tail io latency when iops
> limit is enforced") wait time could be zero even if group is throttled and
> cannot issue requests right now. As a result throtl_select_dispatch() turns
> into busy-loop under irq-safe queue spinlock.
>
> Fix is simple: always round up target time to the next throttle slice.
>
> Fixes: 991f61fe7e1d ("Blk-throttle: reduce tail io latency when iops limit is
> enforced")
> Signed-off-by: Konstantin Khlebnikov
> Cc: sta...@vger.kernel.org # v4.19+
> ---
> block/blk-throttle.c |9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/block/blk-throttle.c b/block/blk-throttle.c
> index 9ea7c0ecad10..8ab6c8153223 100644
> --- a/block/blk-throttle.c
> +++ b/block/blk-throttle.c
> @@ -881,13 +881,10 @@ static bool tg_with_in_iops_limit(struct throtl_grp
> *tg, struct bio *bio,
> unsigned long jiffy_elapsed, jiffy_wait, jiffy_elapsed_rnd;
> u64 tmp;
>
> - jiffy_elapsed = jiffy_elapsed_rnd = jiffies - tg->slice_start[rw];
> -
> - /* Slice has just started. Consider one slice interval */
> - if (!jiffy_elapsed)
> - jiffy_elapsed_rnd = tg->td->throtl_slice;
> + jiffy_elapsed = jiffies - tg->slice_start[rw];
>
> - jiffy_elapsed_rnd = roundup(jiffy_elapsed_rnd, tg->td->throtl_slice);
> + /* Round up to the next throttle slice, wait time must be nonzero */
> + jiffy_elapsed_rnd = roundup(jiffy_elapsed + 1, tg->td->throtl_slice);
>
> /*
>* jiffy_elapsed_rnd should not be a big value as minimum iops can be
Did you use a tiny iops limit to run into this?
thanks,
-liubo
Re: [PATCH] selftests/ftrace: avoid failure when trying to probe a notrace function
On Mon, Jul 08, 2019 at 02:56:18PM -0400, Steven Rostedt wrote: > On Mon, 8 Jul 2019 15:19:33 -0300 > Thadeu Lima de Souza Cascardo wrote: > > > Check that the function is on available_filter_functions. If it's not, > > mark the test as unresolved, instead of failing it. > > > > Actually, I sent this out a while ago: > > http://lkml.kernel.org/r/20190322150923.1b58e...@gandalf.local.home > > Does that fix it for you? > > -- Steve Yes, that fix it for me, let me reply to the original message. Thanks! Cascardo. > > > > Signed-off-by: Thadeu Lima de Souza Cascardo > > --- > > tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > > b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > > index 3fb70e01b1fe..e4dff034da12 100644 > > --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > > @@ -26,6 +26,7 @@ test -d events/kprobes2/event2 || exit_failure > > > > FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f > > 3 -d " "` > > [ "x" != "x$FUNC" ] || exit_unresolved > > +grep -n "$FUNC" available_filter_functions || exit_unresolved > > echo "p $FUNC" > kprobe_events > > EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:` > > [ "x" != "x$EVENT" ] || exit_failure >
[PATCH 3/4] tty: n_gsm: add helper to convert mux-num to/from tty-base
Make it obvious how the gsm mux number relates to the virtual tty lines
by using helper function instead of shifting 6 bits.
Signed-off-by: Martin Hundebøll
---
drivers/tty/n_gsm.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c4e16b31f9ab..cba06063c44a 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2171,6 +2171,16 @@ static inline void mux_put(struct gsm_mux *gsm)
kref_put(>ref, gsm_free_muxr);
}
+static inline int mux_num_to_base(struct gsm_mux *gsm)
+{
+ return gsm->num * NUM_DLCI;
+}
+
+static inline unsigned int mux_line_to_num(int line)
+{
+ return line / NUM_DLCI;
+}
+
/**
* gsm_alloc_mux - allocate a mux
*
@@ -2361,7 +2371,7 @@ static int gsmld_attach_gsm(struct tty_struct *tty,
struct gsm_mux *gsm)
else {
/* Don't register device 0 - this is the control channel and not
a usable tty interface */
- base = gsm->num << 6; /* Base for this MUX */
+ base = mux_num_to_base(gsm); /* Base for this MUX */
for (i = 1; i < NUM_DLCI; i++)
tty_register_device(gsm_tty_driver, base + i, NULL);
}
@@ -2380,7 +2390,7 @@ static int gsmld_attach_gsm(struct tty_struct *tty,
struct gsm_mux *gsm)
static void gsmld_detach_gsm(struct tty_struct *tty, struct gsm_mux *gsm)
{
int i;
- int base = gsm->num << 6; /* Base for this MUX */
+ int base = mux_num_to_base(gsm); /* Base for this MUX */
WARN_ON(tty != gsm->tty);
for (i = 1; i < NUM_DLCI; i++)
@@ -2908,7 +2918,7 @@ static int gsmtty_install(struct tty_driver *driver,
struct tty_struct *tty)
struct gsm_mux *gsm;
struct gsm_dlci *dlci;
unsigned int line = tty->index;
- unsigned int mux = line >> 6;
+ unsigned int mux = mux_line_to_num(line);
bool alloc = false;
int ret;
--
2.22.0
[PATCH 2/4] tty: n_gsm: update doc example to use header for N_GSM0710 define
There is no reason to gues the line discipline number when it is available from tty.h Signed-off-by: Martin Hundebøll --- Documentation/serial/n_gsm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/serial/n_gsm.rst b/Documentation/serial/n_gsm.rst index 78f91ce06956..a3ce1b269018 100644 --- a/Documentation/serial/n_gsm.rst +++ b/Documentation/serial/n_gsm.rst @@ -23,7 +23,7 @@ Major parts of the initialization program : (a good starting point is util-linux-ng/sys-utils/ldattach.c):: #include - #define N_GSM071021 /* GSM 0710 Mux */ + #include #define DEFAULT_SPEEDB115200 #define SERIAL_PORT /dev/ttyS0 -- 2.22.0
[PATCH 4/4] tty: n_gsm: add ioctl to map serial device to mux'ed tty
Guessing the base tty for a gsm0710 multiplexed serial device is not
currently possible, which makes it racy to use with multiple modems.
Add a way to map the physical serial tty to its related mux devices
using a ioctl.
Signed-off-by: Martin Hundebøll
---
Documentation/serial/n_gsm.rst | 8
drivers/tty/n_gsm.c| 6 ++
include/uapi/linux/gsmmux.h| 2 ++
3 files changed, 16 insertions(+)
diff --git a/Documentation/serial/n_gsm.rst b/Documentation/serial/n_gsm.rst
index a3ce1b269018..bf5d7f82b5af 100644
--- a/Documentation/serial/n_gsm.rst
+++ b/Documentation/serial/n_gsm.rst
@@ -18,10 +18,12 @@ How to use it
2. switch the serial line to using the n_gsm line discipline by using
TIOCSETD ioctl,
3. configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl,
+4. obtain base gsmtty number for the used serial port,
Major parts of the initialization program :
(a good starting point is util-linux-ng/sys-utils/ldattach.c)::
+ #include
#include
#include
#define DEFAULT_SPEEDB115200
@@ -30,6 +32,7 @@ Major parts of the initialization program :
int ldisc = N_GSM0710;
struct gsm_config c;
struct termios configuration;
+ int base;
/* open the serial port connected to the modem */
fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY);
@@ -58,6 +61,11 @@ Major parts of the initialization program :
c.mtu = 127;
/* set the new configuration */
ioctl(fd, GSMIOC_SETCONF, );
+ /* get and print base gsmtty device node */
+ ioctl(fd, GSMIOC_GETBASE, );
+ /* the base node is used for mux control by the driver */
+ printf(first muxed line: /dev/gsmtty%i\n", base + 1);
+
/* and wait for ever to keep the line discipline enabled */
daemon(0,0);
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index cba06063c44a..93c24d9b582b 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2612,6 +2612,7 @@ static int gsmld_ioctl(struct tty_struct *tty, struct
file *file,
{
struct gsm_config c;
struct gsm_mux *gsm = tty->disc_data;
+ int base;
switch (cmd) {
case GSMIOC_GETCONF:
@@ -2623,6 +2624,11 @@ static int gsmld_ioctl(struct tty_struct *tty, struct
file *file,
if (copy_from_user(, (void *)arg, sizeof(c)))
return -EFAULT;
return gsm_config(gsm, );
+ case GSMIOC_GETBASE:
+ base = mux_num_to_base(gsm);
+ if (copy_to_user((void *)arg, , sizeof(base)))
+ return -EFAULT;
+ return 0;
default:
return n_tty_ioctl_helper(tty, file, cmd, arg);
}
diff --git a/include/uapi/linux/gsmmux.h b/include/uapi/linux/gsmmux.h
index 101d3c469acb..6eb63be3ed9e 100644
--- a/include/uapi/linux/gsmmux.h
+++ b/include/uapi/linux/gsmmux.h
@@ -37,5 +37,7 @@ struct gsm_netconfig {
#define GSMIOC_ENABLE_NET _IOW('G', 2, struct gsm_netconfig)
#define GSMIOC_DISABLE_NET _IO('G', 3)
+/* get the base tty number for a configured gsmmux tty */
+#define GSMIOC_GETBASE _IOR('G', 4, int)
#endif
--
2.22.0
[PATCH 1/4] tty: n_gsm: remove obsolete mknod doc example
The n_gsm driver handles registration of /dev/gsmttyX nodes, so there's
no need to do mknod manually.
Signed-off-by: Martin Hundebøll
---
Documentation/serial/n_gsm.rst | 10 --
1 file changed, 10 deletions(-)
diff --git a/Documentation/serial/n_gsm.rst b/Documentation/serial/n_gsm.rst
index f3ad9fd26408..78f91ce06956 100644
--- a/Documentation/serial/n_gsm.rst
+++ b/Documentation/serial/n_gsm.rst
@@ -63,16 +63,6 @@ Major parts of the initialization program :
daemon(0,0);
pause();
-4. create the devices corresponding to the "virtual" serial ports (take care,
- each modem has its configuration and some DLC have dedicated functions,
- for example GPS), starting with minor 1 (DLC0 is reserved for the management
- of the mux)::
-
- MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}`
- for i in `seq 1 4`; do
- mknod /dev/ttygsm$i c $MAJOR $i
- done
-
5. use these devices as plain serial ports.
for example, it's possible:
--
2.22.0
Re: [PATCH v1 5/6] mm: Add logic for separating "aerated" pages from "raw" pages
On Tue, 2019-06-25 at 13:24 -0700, Dave Hansen wrote:
> On 6/19/19 3:33 PM, Alexander Duyck wrote:
> > Add a set of pointers we shall call "boundary" which represents the upper
> > boundary between the "raw" and "aerated" pages. The general idea is that in
> > order for a page to cross from one side of the boundary to the other it
> > will need to go through the aeration treatment.
>
> Aha! The mysterious "boundary"!
>
> But, how can you introduce code that deals with boundaries before
> introducing the boundary itself? Or was that comment misplaced?
The comment in the earlier patch was misplaced. Basically the logic before
this patch would just add the aerated pages directly to the tail of the
free_list, however if it had to leave and come back there was nothing to
prevent us from creating a mess of interleaved "raw" and "aerated" pages.
With this patch we are guaranteed that any "raw" pages are added above the
"aerated" pages and will be pulled for processing.
> FWIW, I'm not a fan of these commit messages. They are really hard to
> map to the data structures.
>
> One goal in this set is to avoid creating new data structures.
> We accomplish that by reusing the free lists to hold aerated and
> non-aerated pages. But, in order to use the existing free list,
> we need a boundary to separate aerated from raw.
>
> Further:
>
> Pages are temporarily removed from the free lists while aerating
> them.
>
> This needs a justification why you chose this path, and also what the
> larger implications are.
Well the big advantage is that we aren't messing with the individual
free_area or free_list structures. My initial implementation was adding a
third pointer to split do the work and it actually had performance
implications as it increased the size of the free_area and zone.
> > By doing this we should be able to make certain that we keep the aerated
> > pages as one contiguous block on the end of each free list. This will allow
> > us to efficiently walk the free lists whenever we need to go in and start
> > processing hints to the hypervisor that the pages are no longer in use.
>
> You don't really walk them though, right? It *keeps* you from having to
> ever walk the lists.
It all depends on your definition of "walk". In the case of this logic we
will have to ultimately do 1 pass over all the "raw" pages to process
them. So I consider that a walk through the free_list. However we can
avoid all of the already processed pages since we have the flag and the
pointer to what should be the top of the list for the "aerated" pages.
> I also don't see what the boundary has to do with aerated pages being on
> the tail of the list. If you want them on the tail, you just always
> list_add_tail() them.
The issue is that there are multiple things that can add to the tail of
the list. For example the shuffle code or the lower order buddy expecting
its buddy to be freed. In those cases I don't want to add to tail so
instead I am adding those to the boundary. By doing that I can avoid
having the tail of the list becoming interleaved with raw and aerated
pages.
> > And added advantage to this approach is that we should be reducing the
> > overall memory footprint of the guest as it will be more likely to recycle
> > warm pages versus the aerated pages that are likely to be cache cold.
>
> I'm confused. Isn't an aerated page non-present on the guest? That's
> worse than cache cold. It costs a VMEXIT to bring back in.
I suppose so, it would be worse than being cache cold.
> > Since we will only be aerating one zone at a time we keep the boundary
> > limited to being defined for just the zone we are currently placing aerated
> > pages into. Doing this we can keep the number of additional poitners needed
> > quite small.
>
> pointers ^
>
> > +struct list_head *__aerator_get_tail(unsigned int order, int migratetype);
> > static inline struct list_head *aerator_get_tail(struct zone *zone,
> > unsigned int order,
> > int migratetype)
> > {
> > +#ifdef CONFIG_AERATION
> > + if (order >= AERATOR_MIN_ORDER &&
> > + test_bit(ZONE_AERATION_ACTIVE, >flags))
> > + return __aerator_get_tail(order, migratetype);
> > +#endif
> > return >free_area[order].free_list[migratetype];
> > }
>
> Logically, I have no idea what this is doing. "Go get pages out of the
> aerated list?" "raw list"? Needs comments.
I'll add comments. Really now that I think about it I should probably
change the name for this anyway. What is really being returned is the tail
for the non-aerated list. Specifically if ZONE_AERATION_ACTIVE is set we
want to prevent any insertions below the list of aerated pages, so we are
returning the first entry in the aerated list and using that as the
tail/head of a list tail insertion.
Ugh. I really need to
NFS Caching broken in 4.19.37
Hi list, NFS caching appears broken in 4.19.37. The more cores/threads the easier to reproduce. Tested with identical results on Ryzen 1600 and 1600X. 1. Mount an openwrt build tree over NFS v4 2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a loop 3. Result after 3-4 iterations: State on the client ls -laF /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm total 8 drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./ drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../ State as seen on the server (mounted via nfs from localhost): ls -laF /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm total 12 drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./ drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../ -rw-r--r-- 1 anivanov anivanov 32 Jul 8 11:40 ipcbuf.h Actual state on the filesystem: ls -laF /exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm total 12 drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./ drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../ -rw-r--r-- 1 anivanov anivanov 32 Jul 8 11:40 ipcbuf.h So the client has quite clearly lost the plot. Telling it to drop caches and re-reading the directory shows the file present. It is possible to reproduce this using a linux kernel tree too, just takes much more iterations - 10+ at least. Both client and server run 4.19.37 from Debian buster. This is filed as debian bug 931500. I originally thought it to be autofs related, but IMHO it is actually something fundamentally broken in nfs caching resulting in cache corruption. -- Anton R. Ivanov Cambridgegreys Limited. Registered in England. Company Number 10273661 https://www.cambridgegreys.com/
Re: [PATCH] selftests/ftrace: avoid failure when trying to probe a notrace function
On Mon, 8 Jul 2019 15:19:33 -0300 Thadeu Lima de Souza Cascardo wrote: > Check that the function is on available_filter_functions. If it's not, > mark the test as unresolved, instead of failing it. > Actually, I sent this out a while ago: http://lkml.kernel.org/r/20190322150923.1b58e...@gandalf.local.home Does that fix it for you? -- Steve > Signed-off-by: Thadeu Lima de Souza Cascardo > --- > tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > index 3fb70e01b1fe..e4dff034da12 100644 > --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc > @@ -26,6 +26,7 @@ test -d events/kprobes2/event2 || exit_failure > > FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3 > -d " "` > [ "x" != "x$FUNC" ] || exit_unresolved > +grep -n "$FUNC" available_filter_functions || exit_unresolved > echo "p $FUNC" > kprobe_events > EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:` > [ "x" != "x$EVENT" ] || exit_failure
Re: [PATCH v3] RDMA/core: Fix race when resolving IP address
Thanks Jason, Regards, Dag Den 08.07.2019 19:50, skrev Jason Gunthorpe: On Mon, Jul 08, 2019 at 01:16:24PM +0200, Dag Moxnes wrote: Use neighbour lock when copying MAC address from neighbour data struct in dst_fetch_ha. When not using the lock, it is possible for the function to race with neigh_update, causing it to copy an invalid MAC address. It is possible to provoke this error by calling rdma_resolve_addr in a tight loop, while deleting the corresponding ARP entry in another tight loop. This will cause the race shown it the following sample trace: rdma_resolve_addr() rdma_resolve_ip() addr_resolve() addr_resolve_neigh() fetch_ha() dst_fetch_ha() n->nud_state == NUD_VALID It isn't nud_state that is the problem here, it is the parallel memcpy's onto ha. I fixed the commit message This could also have been solved by using the ha_lock, but I don't think we have a reason to particularly over-optimize this. drivers/infiniband/core/addr.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) Applied to for-next, thanks Jason
RE: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3)
> -Original Message- > From: Leo Li > Sent: Monday, June 17, 2019 8:29 AM > To: Olof Johansson > Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; shawn...@kernel.org > Subject: RE: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3) > > > > > -Original Message- > > From: Olof Johansson > > Sent: Monday, June 17, 2019 6:50 AM > > To: Leo Li > > Cc: a...@kernel.org; linux-arm-ker...@lists.infradead.org; linux- > > ker...@vger.kernel.org; shawn...@kernel.org > > Subject: Re: [GIT PULL v2] updates to soc/fsl drivers for next(v5.3) > > > > On Wed, Jun 05, 2019 at 02:45:11PM -0500, Li Yang wrote: > > > Hi arm-soc maintainers, > > > > > > This is a rebase of patches that missed 5.2 merge window together > > > with some new patches for QE. Please help to review and merge it. > > > We would like this to be merged earlier because there are other > > > patches depending on patches in this pull request. After this is > > > merged in arm-soc, we can ask other sub-system maintainers to pull > > > from this tag and apply additional patches. Thanks. > > > > Li, > > > > You never followed up with a reply, or removed, the previous tag. So > > when we process the pull requests that come in, we've already merged it. > > Sorry about that. Will reply the previous pull request and remove the old tag > if update is needed next time. > > > > > So, I've merged the previous version. Can you send an incremental pull > > request on top of that branch/tag instead of a rebase like this was, please? > > Actually the new pull request is based on the old pull request this time. I > sent the new one as V2 hoping that you can see this first and avoid merging > two times. Since you have already merged the first one, you can merge the > second pull request as an incremental pull request directly. Hi Olof, I was on vacation for the past two weeks to follow up on this. Hope this is not too late for this merge window. Like I mentioned, the new tag is on top of the previous tag (you merged) so that it should be able to be merged incrementally. The only thing is that the description of the new tag also included patches you merged with old tag. Do you want me to regenerate the tag before you can merge it? Regards, Leo
Re: [PATCH v2] remoteproc: copy parent dma_pfn_offset for vdev
On Tue, Jul 02, 2019 at 03:36:56PM +, Loic PALLARDY wrote: > Agree there is definitively an issue with the way virtio device are defined. > Today definition is based on rproc firmware ressource table and rproc > framework is in charge of vdev creation. > Device tree definition was discarded as vdev is not HW but SW definition. Well, it appears to be a firmware interface description. > One solution would be to associate both resource table (which provides > Firmware capabilities) and some virtio device tree nodes (declared as sub > nodes > of remote processor with associated resources like memory carveout). > When we have a match between resource table and rproc DT sub node, we > can register virtio device via of_platform_populate. > Then need to adapt virtio_rpmsg or to create a virtio_rproc to be DT probe > compliant > like virtio_mmio is. > > But that's breaking legacy as all platforms will have to add a virtio device > node in > their DT file... > > Is it aligned with your view ? Yes, that is how I'd assume it works. But given that until recently you did now have these subdevices for dma coherent purposes we can't really break anything older than that, so I might still be missing something.
Re: [PATCH] selftests/seccomp/seccomp_bpf: update for PTRACE_GET_SYSCALL_INFO
On Mon, Jul 8, 2019 at 11:29 AM Dmitry V. Levin wrote: > > The syscall entry/exit is now exposed via PTRACE_GETEVENTMSG, > update the test accordingly. Reviewed-by: Andy Lutomirski
Re: mmotm 2019-07-06-22-00 uploaded
On Mon, Jul 8, 2019 at 7:29 AM Arnd Bergmann wrote:
>
> On Sun, Jul 7, 2019 at 7:05 AM wrote:
>
> > * mm-move-mem_cgroup_uncharge-out-of-__page_cache_release.patch
> > * mm-shrinker-make-shrinker-not-depend-on-memcg-kmem.patch
> > * mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix.patch
> > * mm-thp-make-deferred-split-shrinker-memcg-aware.patch
>
> mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix.patch fixes
> the compile-time error when memcg_expand_shrinker_maps() is not
> declared, but now we get a linker error instead because the
> function is still not built into the kernel:
>
> mm/vmscan.o: In function `prealloc_shrinker':
> vmscan.c:(.text+0x328): undefined reference to `memcg_expand_shrinker_maps'
Sorry for chiming in late, I just came back from vacation.
The below patch should fix the issue, which is for linux-next
2019-07-08 on top of Andrew's fix. And, this patch fixed the redundant
#ifdef CONFIG_MEMCG problem pointed out by Randy. Copied Randy too.
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index b7a1f98..5c4b15eb 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -128,9 +128,8 @@ struct mem_cgroup_per_node {
struct mem_cgroup_reclaim_iter iter[DEF_PRIORITY + 1];
-#ifdef CONFIG_MEMCG
struct memcg_shrinker_map __rcu *shrinker_map;
-#endif
+
struct rb_node tree_node; /* RB tree node */
unsigned long usage_in_excess;/* Set to the value by which */
/* the soft limit is exceeded*/
@@ -1296,6 +1295,8 @@ static inline bool
mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg)
struct kmem_cache *memcg_kmem_get_cache(struct kmem_cache *cachep);
void memcg_kmem_put_cache(struct kmem_cache *cachep);
extern int memcg_expand_shrinker_maps(int new_id);
+extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
+ int nid, int shrinker_id);
#ifdef CONFIG_MEMCG_KMEM
int __memcg_kmem_charge(struct page *page, gfp_t gfp, int order);
@@ -1363,8 +1364,6 @@ static inline int memcg_cache_id(struct mem_cgroup *memcg)
return memcg ? memcg->kmemcg_id : -1;
}
-extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
- int nid, int shrinker_id);
#else
static inline int memcg_kmem_charge(struct page *page, gfp_t gfp, int order)
@@ -1405,9 +1404,6 @@ static inline void memcg_get_cache_ids(void)
static inline void memcg_put_cache_ids(void)
{
}
-
-static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
- int nid, int shrinker_id) { }
#endif /* CONFIG_MEMCG_KMEM */
#endif /* _LINUX_MEMCONTROL_H */
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2ce3bda..dca063b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -313,6 +313,7 @@ void memcg_put_cache_ids(void)
EXPORT_SYMBOL(memcg_kmem_enabled_key);
struct workqueue_struct *memcg_kmem_cache_wq;
+#endif
static int memcg_shrinker_map_size;
static DEFINE_MUTEX(memcg_shrinker_map_mutex);
@@ -436,14 +437,6 @@ void memcg_set_shrinker_bit(struct mem_cgroup
*memcg, int nid, int shrinker_id)
}
}
-#else /* CONFIG_MEMCG_KMEM */
-static int memcg_alloc_shrinker_maps(struct mem_cgroup *memcg)
-{
- return 0;
-}
-static void memcg_free_shrinker_maps(struct mem_cgroup *memcg) { }
-#endif /* CONFIG_MEMCG_KMEM */
-
/**
* mem_cgroup_css_from_page - css of the memcg associated with a page
* @page: page of interest
>
> Arnd
>
[PATCH] selftests/seccomp/seccomp_bpf: update for PTRACE_GET_SYSCALL_INFO
The syscall entry/exit is now exposed via PTRACE_GETEVENTMSG, update the test accordingly. Reported-by: kernel test robot Signed-off-by: Dmitry V. Levin --- tools/testing/selftests/seccomp/seccomp_bpf.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c index dc66fe852768..6ef7f16c4cf5 100644 --- a/tools/testing/selftests/seccomp/seccomp_bpf.c +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c @@ -1775,13 +1775,18 @@ void tracer_ptrace(struct __test_metadata *_metadata, pid_t tracee, unsigned long msg; static bool entry; - /* Make sure we got an empty message. */ + /* +* The traditional way to tell PTRACE_SYSCALL entry/exit +* is by counting. +*/ + entry = !entry; + + /* Make sure we got an appropriate message. */ ret = ptrace(PTRACE_GETEVENTMSG, tracee, NULL, ); EXPECT_EQ(0, ret); - EXPECT_EQ(0, msg); + EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY + : PTRACE_EVENTMSG_SYSCALL_EXIT, msg); - /* The only way to tell PTRACE_SYSCALL entry/exit is by counting. */ - entry = !entry; if (!entry) return; -- ldv
Re: [PATCH] r8169: add enable_aspm parameter
On 08.07.2019 08:37, AceLan Kao wrote:
> We have many commits in the driver which enable and then disable ASPM
> function over and over again.
>commit b75bb8a5b755 ("r8169: disable ASPM again")
>commit 0866cd15029b ("r8169: enable ASPM on RTL8106E")
>commit 94235460f9ea ("r8169: Align ASPM/CLKREQ setting function with
> vendor driver")
>commit aa1e7d2c31ef ("r8169: enable ASPM on RTL8168E-VL")
>commit f37658da21aa ("r8169: align ASPM entry latency setting with vendor
> driver")
>commit a99790bf5c7f ("r8169: Reinstate ASPM Support")
>commit 671646c151d4 ("r8169: Don't disable ASPM in the driver")
>commit 4521e1a94279 ("Revert "r8169: enable internal ASPM and clock
> request settings".")
>commit d64ec841517a ("r8169: enable internal ASPM and clock request
> settings")
>
> This function is very important for production, and if we can't come out
> a solution to make both happy, I'd suggest we add a parameter in the
> driver to toggle it.
>
The usage of a module parameter to control ASPM is discouraged.
There have been more such attempts in the past that have been declined.
Pending with the PCI maintainers is a series adding ASPM control
via sysfs, see here: https://www.spinics.net/lists/linux-pci/msg83228.html
Also more details than just stating "it's important for production"
would have been appreciated in the commit message, e.g. which
power-savings you can achieve with ASPM on which systems.
Re: [PATCH 2/2] x86/numa: instance all parsed numa node
On Mon, 8 Jul 2019, Andy Lutomirski wrote: > > On Jul 8, 2019, at 3:35 AM, Thomas Gleixner wrote: > > Anything less than the actual number of present CPUs is problematic except > > you use the 'let's hope nothing happens' approach. We could add an option > > to stop the bringup at the early online state similar to what we do for > > 'nosmt'. > > > How about we change nr_cpus to do that instead so we never have to have > this conversation again? Actually not the worst idea. We have all the infrastructure already. Thanks, tglx
[PATCH] selftests/ftrace: avoid failure when trying to probe a notrace function
Check that the function is on available_filter_functions. If it's not, mark the test as unresolved, instead of failing it. Signed-off-by: Thadeu Lima de Souza Cascardo --- tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc index 3fb70e01b1fe..e4dff034da12 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc @@ -26,6 +26,7 @@ test -d events/kprobes2/event2 || exit_failure FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3 -d " "` [ "x" != "x$FUNC" ] || exit_unresolved +grep -n "$FUNC" available_filter_functions || exit_unresolved echo "p $FUNC" > kprobe_events EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:` [ "x" != "x$EVENT" ] || exit_failure -- 2.20.1
Re: [PATCH] net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC
From: David Miller Date: Sun, 07 Jul 2019 22:18:05 -0700 (PDT) > From: Jiangfeng Xiao > Date: Fri, 5 Jul 2019 14:10:03 +0800 > >> HI13X1 changed the offsets and bitmaps for tx_desc >> registers in the same peripheral device on different >> models of the hip04_eth. >> >> Signed-off-by: Jiangfeng Xiao > > Applied. Actually I didn't apply this because I can't see that HI13X1_GMAC kconfig knob anywhere in the tree at all.
[PATCH] mfd: cros_ec: Update cros_ec_commands.h
Update cros_ec_commands.h to match the fingerprint MCU section in
the current ec_commands.h
Signed-off-by: Yicheng Li
---
include/linux/mfd/cros_ec_commands.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 7ccb8757b79d..98415686cbfa 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -5513,6 +5513,18 @@ struct ec_params_fp_seed {
uint8_t seed[FP_CONTEXT_TPM_BYTES];
} __ec_align4;
+#define EC_CMD_FP_ENC_STATUS 0x0409
+
+/* FP TPM seed has been set or not */
+#define FP_ENC_STATUS_SEED_SET BIT(0)
+
+struct ec_response_fp_encryption_status {
+ /* Used bits in encryption engine status */
+ uint32_t valid_flags;
+ /* Encryption engine status */
+ uint32_t status;
+} __ec_align4;
+
/*/
/* Touchpad MCU commands: range 0x0500-0x05FF */
--
2.20.1
Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
On Mon, 2019-07-08 at 19:27 +0200, Michal Kubecek wrote: > > Second reason is that with 8-bit genetlink command/message id, the space > is not as infinite as it might seem. FWIW, there isn't really any good reason for this, we have like 16 reserved bits in the genl header. OTOH, having a LOT of ops will certainly cost space in the kernel image... johannes
Re: [PATCH for 5.2] rseq/selftests: Fix Thumb mode build failure on arm32
On 7/8/19 11:58 AM, Mathieu Desnoyers wrote: - On Jun 30, 2019, at 9:56 AM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: Using ".arm .inst" for the arm signature introduces build issues for programs compiled in Thumb mode because the assembler stays in the arm mode for the rest of the inline assembly. Revert to using a ".word" to express the signature as data instead. The choice of signature is a valid trap instruction on arm32 little endian, where both code and data are little endian. ARMv6+ big endian (BE8) generates mixed endianness code vs data: little-endian code and big-endian data. The data value of the signature needs to have its byte order reversed to generate the trap instruction. Prior to ARMv6, -mbig-endian generates big-endian code and data (which match), so the endianness of the data representation of the signature should not be reversed. However, the choice between BE32 and BE8 is done by the linker, so we cannot know whether code and data endianness will be mixed before the linker is invoked. So rather than try to play tricks with the linker, the rseq signature is simply data (not a trap instruction) prior to ARMv6 on big endian. This is why the signature is expressed as data (.word) rather than as instruction (.inst) in assembler. Because a ".word" is used to emit the signature, it will be interpreted as a literal pool by a disassembler, not as an actual instruction. Considering that the signature is not meant to be executed except in scenarios where the program execution is completely bogus, this should not be an issue. Now that 5.2 is out before this patch has been merged, can we please integrate this patch through the kernel selftests or ARM tree so it can be merged into the stable 5.2 branch ? I will apply it to selftests and send it for 5.3-rc1 and mark it for stable. thanks, -- Shuah
Re: [PATCH v2 1/2] leds: tlc591xx: simplify driver by using the managed led API
JJ
On 7/8/19 5:06 AM, Jean-Jacques Hiblot wrote:
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices
What changed from v1?
I don't see any changes especially the bounds on the reg property.
Dan
Signed-off-by: Jean-Jacques Hiblot
---
drivers/leds/leds-tlc591xx.c | 79 +---
1 file changed, 20 insertions(+), 59 deletions(-)
diff --git a/drivers/leds/leds-tlc591xx.c b/drivers/leds/leds-tlc591xx.c
index 59ff088c7d75..3d5a4b92f016 100644
--- a/drivers/leds/leds-tlc591xx.c
+++ b/drivers/leds/leds-tlc591xx.c
@@ -128,51 +128,6 @@ tlc591xx_brightness_set(struct led_classdev *led_cdev,
return err;
}
-static void
-tlc591xx_destroy_devices(struct tlc591xx_priv *priv, unsigned int j)
-{
- int i = j;
-
- while (--i >= 0) {
- if (priv->leds[i].active)
- led_classdev_unregister(>leds[i].ldev);
- }
-}
-
-static int
-tlc591xx_configure(struct device *dev,
- struct tlc591xx_priv *priv,
- const struct tlc591xx *tlc591xx)
-{
- unsigned int i;
- int err = 0;
-
- tlc591xx_set_mode(priv->regmap, MODE2_DIM);
- for (i = 0; i < TLC591XX_MAX_LEDS; i++) {
- struct tlc591xx_led *led = >leds[i];
-
- if (!led->active)
- continue;
-
- led->priv = priv;
- led->led_no = i;
- led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
- led->ldev.max_brightness = LED_FULL;
- err = led_classdev_register(dev, >ldev);
- if (err < 0) {
- dev_err(dev, "couldn't register LED %s\n",
- led->ldev.name);
- goto exit;
- }
- }
-
- return 0;
-
-exit:
- tlc591xx_destroy_devices(priv, i);
- return err;
-}
-
static const struct regmap_config tlc591xx_regmap = {
.reg_bits = 8,
.val_bits = 8,
@@ -225,7 +180,11 @@ tlc591xx_probe(struct i2c_client *client,
i2c_set_clientdata(client, priv);
+ tlc591xx_set_mode(priv->regmap, MODE2_DIM);
+
for_each_child_of_node(np, child) {
+ struct tlc591xx_led *led;
+
err = of_property_read_u32(child, "reg", );
if (err) {
of_node_put(child);
@@ -236,22 +195,25 @@ tlc591xx_probe(struct i2c_client *client,
of_node_put(child);
return -EINVAL;
}
- priv->leds[reg].active = true;
- priv->leds[reg].ldev.name =
+ led = >leds[reg];
+
+ led->active = true;
+ led->ldev.name =
of_get_property(child, "label", NULL) ? : child->name;
- priv->leds[reg].ldev.default_trigger =
+ led->ldev.default_trigger =
of_get_property(child, "linux,default-trigger", NULL);
- }
- return tlc591xx_configure(dev, priv, tlc591xx);
-}
-
-static int
-tlc591xx_remove(struct i2c_client *client)
-{
- struct tlc591xx_priv *priv = i2c_get_clientdata(client);
-
- tlc591xx_destroy_devices(priv, TLC591XX_MAX_LEDS);
+ led->priv = priv;
+ led->led_no = reg;
+ led->ldev.brightness_set_blocking = tlc591xx_brightness_set;
+ led->ldev.max_brightness = LED_FULL;
+ err = devm_led_classdev_register(dev, >ldev);
+ if (err < 0) {
+ dev_err(dev, "couldn't register LED %s\n",
+ led->ldev.name);
+ return err;
+ }
+ }
return 0;
}
@@ -268,7 +230,6 @@ static struct i2c_driver tlc591xx_driver = {
.of_match_table = of_match_ptr(of_tlc591xx_leds_match),
},
.probe = tlc591xx_probe,
- .remove = tlc591xx_remove,
.id_table = tlc591xx_id,
};
Re: linux-next: Tree for Jul 8 --> bootup failure on s390x (bisected)
On Mon, Jul 08, 2019 at 06:52:14PM +0200, Christian Borntraeger wrote:
> smp: Brought up 1 node, 1 CPU
> Unable to handle kernel pointer dereference in virtual kernel address space
> Failing address: 3a07 TEID: 3a070407
> Fault in home space mode while using kernel ASCE.
> AS:3a780007 R3:7ffd0007 S:7ffd4800 P:3a07021d
> Oops: 0004 ilc:2 [#1] SMP
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5-00101-gcb8f0b366109 #14
> Hardware name: IBM 2964 NC9 712 (KVM/Linux)
> Krnl PSW : 0704e0018000 3974b580
> (shmem_parse_monolithic+0x88/0x100)
>R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
> Krnl GPRS: 003d 3a07040e 003d
>3a07040f 006d 0001
>7f7c1c00 3a07040a
>7f7e4000 3a190d78 3974b56c 03e00031fd38
> Krnl Code: 3974b574: b920002a cgr %r2,%r10
>3974b578: a784001b brc 8,3974b5ae
> #3974b57c: 41402001 la %r4,1(%r2)
> >3974b580: 92002000 mvi 0(%r2),0
>3974b584: a709 lghi%r0,0
>3974b588: b9040014 lgr %r1,%r4
>3974b58c: b25e0001 srst%r0,%r1
>3974b590: a714fffe brc 1,3974b58c
> Call Trace:
> ([<03e00031fd80>] 0x3e00031fd80)
> [<39811662>] vfs_kern_mount.part.0+0x9a/0xc8
> [<3a302fc0>] devtmpfs_init+0x38/0x140
> [<3a302e0a>] driver_init+0x22/0x60
> [<3a2beff8>] kernel_init_freeable+0x298/0x4f0
> [<39e7b53a>] kernel_init+0x22/0x148
> [<39e87b70>] ret_from_fork+0x30/0x34
> [<39e87b74>] kernel_thread_starter+0x0/0xc
> INFO: lockdep is turned off.
> [...]
Oh, fuck... OK, I understand what's going on; sorry, my fault. Could you
verify that the following helps?
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index 52312c665a38..30d0523014e0 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -431,9 +431,10 @@ static int devtmpfsd(void *p)
*/
int __init devtmpfs_init(void)
{
+ char opts[] = "mode=0755";
int err;
- mnt = vfs_kern_mount(_fs_type, 0, "devtmpfs", "mode=0755");
+ mnt = vfs_kern_mount(_fs_type, 0, "devtmpfs", opts);
if (IS_ERR(mnt)) {
printk(KERN_ERR "devtmpfs: unable to create devtmpfs %ld\n",
PTR_ERR(mnt));
Re: [PATCH] rtw88/pci: Rearrange the memory usage for skb in RX ISR
On 7/8/19 1:32 AM, Jian-Hong Pan wrote:
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index cfe05ba7280d..1bfc99ae6b84 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -786,6 +786,15 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct
rtw_pci *rtwpci,
rx_desc = skb->data;
chip->ops->query_rx_desc(rtwdev, rx_desc, _stat,
_status);
+ /* discard current skb if the new skb cannot be allocated as a
+* new one in rx ring later
+* */
+ new = dev_alloc_skb(RTK_PCI_RX_BUF_SIZE);
+ if (WARN(!new, "rx routine starvation\n")) {
+ new = skb;
+ goto next_rp;
This should probably be a WARN_ONCE() rather than WARN(), otherwise the logs
will be flooded once this condition triggers.
Larry
