[PATCH] MAINTAINERS: update QUALCOMM IOMMU after Arm SSMU drivers move
Commit e86d1aa8b60f ("iommu/arm-smmu: Move Arm SMMU drivers into their own
subdirectory") moved drivers/iommu/qcom_iommu.c to
drivers/iommu/arm/arm-smmu/qcom_iommu.c amongst other moves, adjusted some
sections in MAINTAINERS, but missed adjusting the QUALCOMM IOMMU section.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matchesF:drivers/iommu/qcom_iommu.c
Update the file entry in MAINTAINERS to the new location.
Signed-off-by: Lukas Bulwahn
---
Will, please ack.
Joerg, please pick this minor non-urgent patch for your -next branch.
applies cleanly on next-20200731
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1469cb81261d..e175c0741653 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14358,7 +14358,7 @@ M: Rob Clark
L: io...@lists.linux-foundation.org
L: linux-arm-...@vger.kernel.org
S: Maintained
-F: drivers/iommu/qcom_iommu.c
+F: drivers/iommu/arm/arm-smmu/qcom_iommu.c
QUALCOMM IPCC MAILBOX DRIVER
M: Manivannan Sadhasivam
--
2.17.1
Re: [PATCH v2] ASoC: fsl-asoc-card: Remove fsl_asoc_card_set_bias_level function
On Sun, Aug 02, 2020 at 10:22:35AM +0800, Shengjiu Wang wrote:
> > > + /* Specific configuration for PLL */
> > > + if (codec_priv->pll_id && codec_priv->fll_id) {
> > > + if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE)
> > > + pll_out = priv->sample_rate * 384;
> > > + else
> > > + pll_out = priv->sample_rate * 256;
> > > +
> > > + ret = snd_soc_dai_set_pll(asoc_rtd_to_codec(rtd, 0),
> > > + codec_priv->pll_id,
> > > + codec_priv->mclk_id,
> > > + codec_priv->mclk_freq, pll_out);
> > > + if (ret) {
> > > + dev_err(dev, "failed to start FLL: %d\n", ret);
> > > + goto out;
> > > + }
> > > +
> > > + ret = snd_soc_dai_set_sysclk(asoc_rtd_to_codec(rtd, 0),
> > > + codec_priv->fll_id,
> > > + pll_out, SND_SOC_CLOCK_IN);
> >
> > Just came into my mind: do we need some protection here to prevent
> > PLL/SYSCLK reconfiguration if TX/RX end up with different values?
> >
> Sorry, not really catching your point. could you please elaborate?
> Why do TX/RX end up with different values?
If TX and RX run concurrently but in different sample rates or
sample formats, pll_out would be overwritten to PLL/SYSCLK?
I remember imx-wm8962 uses SSI, having symmetric flags for rates/
channels/samplebits, but fsl-asoc-card might have (or will have)
other use case.
If all existing combinations don't have any problem, we can add
a protection later when we need.
Re: WARNING in hci_conn_timeout
On Sat, Aug 01, 2020 at 03:56:09PM -0700, syzbot wrote: > syzbot has bisected this issue to: > > commit 3d30311c0e4d834c94e6a27d6242a942d6a76b85 > Author: Varsha Rao > Date: Sun Oct 9 11:13:56 2016 + > > staging: vt6655: Removes unnecessary blank lines. I doubt this is the real issue :(
Re: [PATCH -next v2] virtio_net: Avoid loop in virtnet_poll
Just noticed the subject is wrong: this is no longer
a virtio_net patch.
On Sun, Aug 02, 2020 at 01:56:33PM +0800, Mao Wenan wrote:
> The loop may exist if vq->broken is true,
> virtqueue_get_buf_ctx_packed or virtqueue_get_buf_ctx_split
> will return NULL, so virtnet_poll will reschedule napi to
> receive packet, it will lead cpu usage(si) to 100%.
>
> call trace as below:
> virtnet_poll
> virtnet_receive
> virtqueue_get_buf_ctx
> virtqueue_get_buf_ctx_packed
> virtqueue_get_buf_ctx_split
> virtqueue_napi_complete
> virtqueue_poll //return true
> virtqueue_napi_schedule //it will reschedule napi
>
> To fix this, return false if vq is broken in virtqueue_poll.
>
> Signed-off-by: Mao Wenan
> ---
> v1->v2: fix it in virtqueue_poll suggested by Michael S. Tsirkin
>
> drivers/virtio/virtio_ring.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 58b96ba..4f7c73e 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -1960,6 +1960,9 @@ bool virtqueue_poll(struct virtqueue *_vq, unsigned
> last_used_idx)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
>
> + if (unlikely(vq->broken))
> + return false;
> +
> virtio_mb(vq->weak_barriers);
> return vq->packed_ring ? virtqueue_poll_packed(_vq, last_used_idx) :
>virtqueue_poll_split(_vq, last_used_idx);
> --
> 1.8.3.1
Re: [PATCH -next v2] virtio_net: Avoid loop in virtnet_poll
On Sun, Aug 02, 2020 at 01:56:33PM +0800, Mao Wenan wrote:
> The loop may exist if vq->broken is true,
> virtqueue_get_buf_ctx_packed or virtqueue_get_buf_ctx_split
> will return NULL, so virtnet_poll will reschedule napi to
> receive packet, it will lead cpu usage(si) to 100%.
>
> call trace as below:
> virtnet_poll
> virtnet_receive
> virtqueue_get_buf_ctx
> virtqueue_get_buf_ctx_packed
> virtqueue_get_buf_ctx_split
> virtqueue_napi_complete
> virtqueue_poll //return true
> virtqueue_napi_schedule //it will reschedule napi
>
> To fix this, return false if vq is broken in virtqueue_poll.
>
> Signed-off-by: Mao Wenan
Looks good:
Acked-by: Michael S. Tsirkin
> ---
> v1->v2: fix it in virtqueue_poll suggested by Michael S. Tsirkin
>
> drivers/virtio/virtio_ring.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 58b96ba..4f7c73e 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -1960,6 +1960,9 @@ bool virtqueue_poll(struct virtqueue *_vq, unsigned
> last_used_idx)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
>
> + if (unlikely(vq->broken))
> + return false;
> +
> virtio_mb(vq->weak_barriers);
> return vq->packed_ring ? virtqueue_poll_packed(_vq, last_used_idx) :
>virtqueue_poll_split(_vq, last_used_idx);
> --
> 1.8.3.1
Re: PCI device function not being enumerated [Was: PCMCIA not working on Panasonic Toughbook CF-29]
Have just had confirmation that the mmc_ricoh_mmc change works and both PCMCIA slots now work as intended on Panasonic Toughbook CF-29 Mk 4 and 5. Thank you to all who have made suggestions for this, your dedication to Linux is amazing and your help with this is appreciated. Stay safe. Michael. On 28/07/2020, Michael . wrote: > I have just compiled and uploaded a kernel to test for this issue, > members of the Toughbook community have been provided with the link, > though a forum discussion, to download the kernel and test it. > Hopefully we will get positive results and can confirm the > MMC_RICOH_MMC flag is the culprit. > Regards. > Stay safe. > Michael. > > On 27/02/2020, bluerocksadd...@willitsonline.com > wrote: >> Somewhere in these messages is a cluein that SD reader was involved. >> >> MK 4 and 5 have SD whilst MK 1, 2 and three do not. >> >> >> >> On 2020-02-25 22:10, Michael . wrote: Someone with access to real hardware could easily experiment with changing that magic value and seeing if it changes which function is disabled. >>> >>> One of our members has offered to supply a machine to a dev that can >>> use it to test any theory. >>> >>> It is nearly beyond the scope of the majority of us to do much more >>> than just testing. We appreciate all the effort the devs put in and >>> are willing to help in anyway we can but we aren't kernel devs. >>> >>> I, personally, use Debian. Others use Debian based distros such as MX >>> and Mint. We have been able to test many different distros such as >>> those listed in other comments but don't have the skills or expertise >>> to do much more. It is our hope that this discussion and subsequent >>> effort may enable others who prefer distros other than Debian based >>> distros can use a CF-29 (and possibly earlier) Toughbook with the >>> distro of their choice without having to rebuild a kernel so they can >>> use hardware that worked back in 2010. To do this the fix needs to be >>> at the kernel dev level not a local enthusiast level because while I >>> can rebuild a Debian kernel I can't rebuild a Fedora or Arch or >>> Slackware kernel. >>> >>> I did a search about this issue before I made initial contact late >>> last year and the issue was discovered on more than Toughbooks and >>> posted about on various sites not long after distros moved from >>> 2.6.32. It seems back then people just got new machines that didn't >>> have a 2nd slot so the search for an answer stopped. Us Toughbook >>> users are a loyal group we use our machines because they are exactly >>> what we need and they take alot of "punishment" taht other machines >>> simply cannot handle. Our machines are used rather than recycled or >>> worse still just left to sit in waste management facilities in a >>> country that the western world dumps its rubbish in, we are Linux and >>> Toughbook enthusiasts and hope to be able to keep our machines running >>> for many years to come with all their native capabilities working as >>> they were designed to but using a modern Linux instead of Windows XP >>> or Windows 7. (that wasn't a pep talk, its just an explanation of why >>> we are passionate about this). >>> >>> Let us know what you need us to do, we will let you know if we are >>> capable of it and give you any feedback you ask for. Over the weekend >>> I will try to rebuild a Debian kernel with the relevant option >>> disabled, provide it to my peers for testing and report back here what >>> the outcome is. >>> >>> Thank you all for all your time and effort, it is truly appreciated. >>> Cheers. >>> Michael. >>> >>> On 26/02/2020, Philip Langdale wrote: On Tue, 25 Feb 2020 23:51:05 -0500 Arvind Sankar wrote: > On Tue, Feb 25, 2020 at 09:12:48PM -0600, Trevor Jacobs wrote: > > That's correct, I tested a bunch of the old distros including > > slackware, and 2.6.32 is where the problem began. > > > > Also, the Panasonic Toughbook CF-29s effected that we tested are > > the later marks, MK4 and MK5 for certain. The MK2 CF-29 worked just > > fine because it has different hardware supporting the PCMCIA slots. > > I have not tested a MK3 but suspect it would work ok as it also > > uses the older hardware. > > > > Thanks for your help guys! > > Trevor > > > > Right, the distros probably all enabled MMC_RICOH_MMC earlier than > upstream. Can you test a custom kernel based off your distro kernel > but just disabling that config option? That's probably the easiest > fix > currently, even though not ideal. Perhaps there should be a command > line option to disable specific pci quirks to make this easier. > > An ideal fix is I feel hard, given this quirk is based on > undocumented > config registers -- it worked on Dell machines (that's where the > original authors seem to have gotten their info from), perhaps they > had only one Cardbus slot, but the code ends up dis
[PATCH -next v2] virtio_net: Avoid loop in virtnet_poll
The loop may exist if vq->broken is true,
virtqueue_get_buf_ctx_packed or virtqueue_get_buf_ctx_split
will return NULL, so virtnet_poll will reschedule napi to
receive packet, it will lead cpu usage(si) to 100%.
call trace as below:
virtnet_poll
virtnet_receive
virtqueue_get_buf_ctx
virtqueue_get_buf_ctx_packed
virtqueue_get_buf_ctx_split
virtqueue_napi_complete
virtqueue_poll //return true
virtqueue_napi_schedule //it will reschedule napi
To fix this, return false if vq is broken in virtqueue_poll.
Signed-off-by: Mao Wenan
---
v1->v2: fix it in virtqueue_poll suggested by Michael S. Tsirkin
drivers/virtio/virtio_ring.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 58b96ba..4f7c73e 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -1960,6 +1960,9 @@ bool virtqueue_poll(struct virtqueue *_vq, unsigned
last_used_idx)
{
struct vring_virtqueue *vq = to_vvq(_vq);
+ if (unlikely(vq->broken))
+ return false;
+
virtio_mb(vq->weak_barriers);
return vq->packed_ring ? virtqueue_poll_packed(_vq, last_used_idx) :
virtqueue_poll_split(_vq, last_used_idx);
--
1.8.3.1
Re: [PATCH mmotm] tmpfs: support 64-bit inums per-sb fix
On Sat, 1 Aug 2020, Randy Dunlap wrote: > On 8/1/20 7:37 PM, Hugh Dickins wrote: > > Expanded Chris's Documentation and Kconfig help on tmpfs inode64. > > TMPFS_INODE64 still there, still default N, but writing down its very > > limited limitation does make me wonder again if we want the option. > > > > Signed-off-by: Hugh Dickins > > --- > > Andrew, please fold into tmpfs-support-64-bit-inums-per-sb.patch later. > > > > Randy, you're very active on Documentation and linux-next: may I ask you > > please to try applying this patch to latest, and see if tmpfs.rst comes > > out looking right to you? I'm an old dog still stuck in the days of > > Hi Hugh, > It looks fine. Thank you so much, Randy. > > > tmpfs.txt, hoping to avoid new tricks for a while. Thanks! (Bonus > > points if you can explain what the "::" on line 122 is about. I started > > out reading Documentation/doc-guide/sphinx.rst, but... got diverted. > > Perhaps I should ask Mauro or Jon, but turning for help first to you.) > > That's the correct file. Around line 216, it says: > > * For inserting fixed width text blocks (for code examples, use case > examples, etc.), use ``::`` for anything that doesn't really benefit > from syntax highlighting, especially short snippets. Use > ``.. code-block:: `` for longer code blocks that benefit > from highlighting. For a short snippet of code embedded in the text, use > \`\`. > > > so it's just for a (short) code example block, fixed font... Bonus points awarded, thanks...ish. I'll have to look around for more examples of where that's done, and I think it'll only make real sense to me, when I'm further along, producing the proper output, then seeing how bad something looks without the "::". Thanks again, Hugh
Re: [PATCH V2 bpf-next] bpf: make __htab_lookup_and_delete_batch faster when map is almost empty
On 8/1/20 11:09 AM, Brian Vazquez wrote:
While running some experiments it was observed that map_lookup_batch was 2x
slower than get_next_key + lookup when the syscall overhead is minimal.
This was because the map_lookup_batch implementation was more expensive
traversing empty buckets, this can be really costly when the pre-allocated
map is too big.
This patch optimizes the case when the bucket is empty so we can move
quickly to next bucket.
The Benchmark was generated using the google/benchmark library[1]. When
the benckmark is executed the number of iterations is governed by the
amount of time the benckmarks takes, the number of iterations is at
least 1 and not more than 1e9, until CPU time(of the entire binary, not
just the part to measure), is greater than 0.5s. Time and CPU reported
are the average of a single iteration over the iteration runs.
The experiments to exercise the empty buckets are as follows:
-The map was populated with a single entry to make sure that the syscall
overhead is not helping the map_batch_lookup.
-The size of the preallocated map was increased to show the effect of
traversing empty buckets.
To interpret the results, Benchmark is the name of the experiment where
the first number correspond to the number of elements in the map, and
the next one correspond to the size of the pre-allocated map. Time and
CPU are average and correspond to the time elapsed per iteration and the
system time consumtion per iteration.
thanks for explanation!
Results:
Using get_next_key + lookup:
BenchmarkTime(ns)CPU(ns) Iteration
---
BM_DumpHashMap/1/1k 3593 3586 192680
BM_DumpHashMap/1/4k 6004 5972 10
BM_DumpHashMap/1/16k15755 15710 44341
BM_DumpHashMap/1/64k59525 59376 1
Using htab_lookup_batch before this patch:
BenchmarkTime(ns)CPU(ns) Iterations
---
BM_DumpHashMap/1/1k 3933 3927 177978
BM_DumpHashMap/1/4k 9192 9177 73951
BM_DumpHashMap/1/16k42011 41970 16789
BM_DumpHashMap/1/64k 117895 117661 6135
Using htab_lookup_batch with this patch:
BenchmarkTime(ns)CPU(ns) Iterations
---
BM_DumpHashMap/1/1k 2809 2803 249212
BM_DumpHashMap/1/4k 5318 5316 10
BM_DumpHashMap/1/16k14925 14895 47448
BM_DumpHashMap/1/64k58870 58674 1
[1] https://github.com/google/benchmark.git
Changelog:
v1 -> v2:
- Add more information about how to interpret the results
Suggested-by: Luigi Rizzo
Cc: Yonghong Song
Signed-off-by: Brian Vazquez
---
kernel/bpf/hashtab.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 024276787055..b6d28bd6345b 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -1349,7 +1349,6 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
struct hlist_nulls_head *head;
struct hlist_nulls_node *n;
unsigned long flags = 0;
- bool locked = false;
struct htab_elem *l;
struct bucket *b;
int ret = 0;
@@ -1408,19 +1407,19 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
dst_val = values;
b = &htab->buckets[batch];
head = &b->head;
- /* do not grab the lock unless need it (bucket_cnt > 0). */
- if (locked)
- flags = htab_lock_bucket(htab, b);
+ l = hlist_nulls_entry_safe(rcu_dereference_raw(hlist_nulls_first_rcu(head)),
+ struct htab_elem, hash_node);
+ if (!l && (batch + 1 < htab->n_buckets)) {
+ batch++;
+ goto again_nocopy;
+ }
In this case, if batch + 1 == htab->n_buckets, we still go through
htab_lock_bucket/htab_unlock_bucket which is really not needed.
So since we are trying to optimize for performance, let us handle
the above case as well. We can do
if (!l) {
if (batch + 1 < htab->n_buckets) {
batch++;
goto again_nocopy;
}
bucket_cnt = 0;
goto done_bucket;
}
...
done_bucket:
rcu_read_unlock();
bpf_enable_instrumentation();
...
what do you think?
+
+ flags = htab_lock_bucket(htab, b);
bucket_cnt = 0;
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
bucket_cnt++;
- if (bucket_cnt && !locked) {
- locked = true;
-
sparse warnings in vop
Hi! Building vop with make C=1 produces the following: CHECK drivers/misc/mic/vop/vop_main.c drivers/misc/mic/vop/vop_main.c:551:58: warning: incorrect type in argument 1 (different address spaces) drivers/misc/mic/vop/vop_main.c:551:58:expected void const volatile [noderef] __iomem *addr drivers/misc/mic/vop/vop_main.c:551:58:got restricted __le64 * drivers/misc/mic/vop/vop_main.c:560:49: warning: incorrect type in argument 1 (different address spaces) drivers/misc/mic/vop/vop_main.c:560:49:expected struct mic_device_ctrl *dc drivers/misc/mic/vop/vop_main.c:560:49:got struct mic_device_ctrl [noderef] __iomem *dc drivers/misc/mic/vop/vop_main.c:579:49: warning: incorrect type in argument 1 (different address spaces) drivers/misc/mic/vop/vop_main.c:579:49:expected struct mic_device_ctrl *dc drivers/misc/mic/vop/vop_main.c:579:49:got struct mic_device_ctrl [noderef] __iomem *dc Would be nice to fix to silence the noise, but I'm not 100% sure what the right thing to do here is. Tag struct members with __iomem or cast with __force on use? -- MST
[PATCH] sched/fair: Fix the logic about active_balance in load_balance()
I think the unbalance scenario here should be that we need to
do active balance but it is not actually done. So fix it.
Signed-off-by: Qi Zheng
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2ba8f230feb9..6d8c53718b67 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9710,7 +9710,7 @@ static int load_balance(int this_cpu, struct rq *this_rq,
} else
sd->nr_balance_failed = 0;
- if (likely(!active_balance) || voluntary_active_balance(&env)) {
+ if (likely(!active_balance) && voluntary_active_balance(&env)) {
/* We were unbalanced, so reset the balancing interval */
sd->balance_interval = sd->min_interval;
} else {
--
2.25.1
Re: [PATCH v2 2/5] drm/mediatek: fix boot up for 720 and 480 but 1080
Hi, Am 2. August 2020 02:08:44 MESZ schrieb Chun-Kuang Hu : >Hi, Frank: >> - disable tmds on phy on mt2701 >> - support other resolutions like 1280x1024 > >If this patch does two things, it should be broken into two patches. As far as i see,it only disable tmds and so fix specific resolutions like the the one below.some other (like 1080p) does not have this Problem. > I think every pll is default off, so you should turn on pll rather > than disable tmds Is disabling tmds wrong here? Which pll is needed here? What does tmds? I got only the Patches for testing >> without this Patch i see flickering on my TFT (1280x1024), >> so i guess clock is wrong. regards Frank
Re: [PATCH v3 2/2] ASoC: qcom: sc7180: Add machine driver for sound card registration
Hi Cheng-Yi, Thank you for the patch! Yet something to improve: [auto build test ERROR on asoc/for-next] [also build test ERROR on linux/master linus/master v5.8-rc7 next-20200731] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Cheng-Yi-Chiang/Add-documentation-and-machine-driver-for-SC7180-sound-card/20200731-164257 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> sound/soc/qcom/sc7180.c:7:10: fatal error: dt-bindings/sound/sc7180-lpass.h: >> No such file or directory 7 | #include | ^~ compilation terminated. vim +7 sound/soc/qcom/sc7180.c 6 > 7 #include 8 #include 9 #include 10 #include 11 #include 12 #include 13 #include 14 #include 15 #include 16 #include 17 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] Modify the parameters that are not used
Signed-off-by: leesagacious
---
include/linux/bottom_half.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/bottom_half.h b/include/linux/bottom_half.h
index a19519f..ab54f34 100644
--- a/include/linux/bottom_half.h
+++ b/include/linux/bottom_half.h
@@ -7,7 +7,8 @@
#ifdef CONFIG_TRACE_IRQFLAGS
extern void __local_bh_disable_ip(unsigned long ip, unsigned int cnt);
#else
-static __always_inline void __local_bh_disable_ip(unsigned long ip, unsigned
int cnt)
+static __always_inline void __local_bh_disable_ip(unsigned long __unused ip,
+ unsigned int cnt)
{
preempt_count_add(cnt);
barrier();
--
2.7.4
Re: [PATCH v2 05/18] gpiolib: cdev: support GPIO_GET_LINE_IOCTL and GPIOLINE_GET_VALUES_IOCTL
On Fri, Jul 31, 2020 at 06:05:10PM +0200, Bartosz Golaszewski wrote:
> On Sun, Jul 26, 2020 at 3:12 AM Kent Gibson wrote:
> >
>
> [snip]
>
> > >
> > > > +static bool padding_not_zeroed(__u32 *padding, int pad_size)
> > > > +{
> > > > + int i, sum = 0;
> > > > +
> > > > + for (i = 0; i < pad_size; i++)
> > > > + sum |= padding[i];
> > > > +
> > > > + return sum;
> > > > +}
> > >
> > > Reimplementation of memchr_inv() ?
> > >
> >
> > I was hoping to find an existing function, surely checking a region is
> > zeroed is a common thing, right?, so this was a place holder as much
> > as anything. Not sure memchr_inv fits the bill, but I'll give it a
> > try...
> >
>
> If you don't find an appropriate function: please put your new
> implementation in lib/ so that others may reuse it.
>
Changed to memchr_inv.
> > > ...
> > >
> > > > +static u64 gpioline_config_flags(struct gpioline_config *lc, int
> > > > line_idx)
> > > > +{
> > > > + int i;
> > > > +
> > > > + for (i = lc->num_attrs - 1; i >= 0; i--) {
> > >
> > > Much better to read is
> > >
> > > unsigned int i = lc->num_attrs;
> > >
> > > while (i--) {
> > > ...
> > > }
> > >
> >
> > Really? I find that the post-decrement in the while makes determining the
> > bounds of the loop more confusing.
> >
>
> Agreed, Andy: this is too much nit-picking. :)
>
I was actually hoping for some feedback on the direction of that loop,
as it relates to the handling of multiple instances of the same
attribute associated with a given line.
The reverse loop here implements a last in wins policy, but I'm now
thinking the kernel should be encouraging userspace to only associate a
given attribute with a line once, and that a first in wins would help do
that - as additional associations would be ignored.
Alternatively, the kernel should enforce that an attribute can only be
associated once, but that would require adding more request validation.
> [snip]
>
> > > ...
> > >
> > > > + struct gpio_desc *desc = gpiochip_get_desc(gdev->chip,
> > > > offset);
> > >
> > > I prefer to see this split, but it's minor.
> > >
> > > > + if (IS_ERR(desc)) {
> > > > + ret = PTR_ERR(desc);
> > > > + goto out_free_line;
> > > > + }
> > >
> > > ...
> > >
> > > > + dev_dbg(&gdev->dev, "registered chardev handle for line
> > > > %d\n",
> > > > + offset);
> > >
> > > Perhaps tracepoint / event?
> > >
> >
> > Again, a cut-and-paste from V1, and I have no experience with
> > tracepoints or events, so I have no opinion on that.
> >
> > So, yeah - perhaps?
> >
>
> I think it's a good idea to add some proper instrumentation this time
> other than much less reliable logs. Can you take a look at
> include/trace/events/gpio.h? Adding new GPIO trace events should be
> pretty straightforward by copy-pasti... drawing inspiration from
> existing ones.
>
You only want tracepoints to replace those dev_dbg()s, so when a line
is requested? What about the release? Any other points?
Cheers,
Kent.
[PATCH] regulator: cros-ec-regulator: Add NULL test for devm_kmemdup call
Fix possible NULL pointer dereference. Signed-off-by: Axel Lin --- drivers/regulator/cros-ec-regulator.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/regulator/cros-ec-regulator.c b/drivers/regulator/cros-ec-regulator.c index 3117bbd2826b..eb3fc1db4edc 100644 --- a/drivers/regulator/cros-ec-regulator.c +++ b/drivers/regulator/cros-ec-regulator.c @@ -170,6 +170,9 @@ static int cros_ec_regulator_init_info(struct device *dev, data->voltages_mV = devm_kmemdup(dev, resp.voltages_mv, sizeof(u16) * data->num_voltages, GFP_KERNEL); + if (!data->voltages_mV) + return -ENOMEM; + data->desc.n_voltages = data->num_voltages; /* Make sure the returned name is always a valid string */ -- 2.25.1
Re: [PATCH v2 4/5] drm/mediatek: dpi/dsi: change the getting possible_crtc way
Hi, Frank:
Frank Wunderlich 於 2020年7月28日 週二 下午7:18寫道：
>
> From: Jitao Shi
>
> [Detail]
> dpi/dsi get the possible_crtc by
> mtk_drm_find_possible_crtc_by_comp(*drm_dev, ddp_comp)
>
I would like more information of why do this patch. For example:
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so call
mtk_drm_find_possible_crtc_by_comp() to find out the correct possible
crtc.
Regards,
Chun-Kuang.
> Test: build pass and boot to logo
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index d4f0fb7ad312..e43977015843 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -608,7 +608,8 @@ static int mtk_dpi_bind(struct device *dev, struct device
> *master, void *data)
> drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
>
> /* Currently DPI0 is fixed to be driven by OVL1 */
> - dpi->encoder.possible_crtcs = BIT(1);
> + dpi->encoder.possible_crtcs =
> + mtk_drm_find_possible_crtc_by_comp(drm_dev, dpi->ddp_comp);
>
> ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL, 0);
> if (ret) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 270bf22c98fe..c31d9c12d4a9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -892,7 +892,8 @@ static int mtk_dsi_create_conn_enc(struct drm_device
> *drm, struct mtk_dsi *dsi)
> * Currently display data paths are statically assigned to a crtc
> each.
> * crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
> */
> - dsi->encoder.possible_crtcs = 1;
> + dsi->encoder.possible_crtcs =
> + mtk_drm_find_possible_crtc_by_comp(drm, dsi->ddp_comp);
>
> /* If there's a bridge, attach to it and let it create the connector
> */
> if (dsi->bridge) {
> --
> 2.25.1
>
Re: [PATCH mmotm] tmpfs: support 64-bit inums per-sb fix
On 8/1/20 7:37 PM, Hugh Dickins wrote: > Expanded Chris's Documentation and Kconfig help on tmpfs inode64. > TMPFS_INODE64 still there, still default N, but writing down its very > limited limitation does make me wonder again if we want the option. > > Signed-off-by: Hugh Dickins > --- > Andrew, please fold into tmpfs-support-64-bit-inums-per-sb.patch later. > > Randy, you're very active on Documentation and linux-next: may I ask you > please to try applying this patch to latest, and see if tmpfs.rst comes > out looking right to you? I'm an old dog still stuck in the days of Hi Hugh, It looks fine. > tmpfs.txt, hoping to avoid new tricks for a while. Thanks! (Bonus > points if you can explain what the "::" on line 122 is about. I started > out reading Documentation/doc-guide/sphinx.rst, but... got diverted. > Perhaps I should ask Mauro or Jon, but turning for help first to you.) That's the correct file. Around line 216, it says: * For inserting fixed width text blocks (for code examples, use case examples, etc.), use ``::`` for anything that doesn't really benefit from syntax highlighting, especially short snippets. Use ``.. code-block:: `` for longer code blocks that benefit from highlighting. For a short snippet of code embedded in the text, use \`\`. so it's just for a (short) code example block, fixed font... > > Documentation/filesystems/tmpfs.rst | 13 ++--- > fs/Kconfig | 16 +++- > 2 files changed, 21 insertions(+), 8 deletions(-) > > --- mmotm/Documentation/filesystems/tmpfs.rst 2020-07-27 18:54:51.116524795 > -0700 > +++ linux/Documentation/filesystems/tmpfs.rst 2020-08-01 18:37:07.719713987 > -0700 cheers. -- ~Randy
Re: [PATCH v2 3/5] drm: Add get_possible_crtc API for dpi, dsi
Hi, Frank:
Frank Wunderlich 於 2020年7月28日 週二 下午7:18寫道：
>
Describe why need this patch. I think the reason is:
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so search
pipeline information to find out the correct possible crtc.
> From: Stu Hsieh
>
> Test: build pass and run ok
>
> Signed-off-by: Stu Hsieh
Need your signed-off-by tag.
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 42 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 57c88de9a329..a5f2ff6bea93 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -13,6 +13,8 @@
> #include
> #include
> #include
> +#include
> +
> #include "mtk_drm_drv.h"
> #include "mtk_drm_plane.h"
> #include "mtk_drm_ddp_comp.h"
> @@ -412,6 +414,22 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
> };
>
> +static bool mtk_drm_find_comp_in_ddp(struct mtk_ddp_comp ddp_comp,
> +const enum mtk_ddp_comp_id *path,
> +unsigned int path_len)
> +{
> + unsigned int i;
> +
> + if (path == NULL)
> + return false;
This checking is redundant, so remove it.
> +
> + for (i = 0U; i < path_len; i++)
> + if (ddp_comp.id == path[i])
> + return true;
> +
> + return false;
> +}
> +
> int mtk_ddp_comp_get_id(struct device_node *node,
> enum mtk_ddp_comp_type comp_type)
> {
> @@ -427,6 +445,30 @@ int mtk_ddp_comp_get_id(struct device_node *node,
> return -EINVAL;
> }
>
> +unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
> + struct mtk_ddp_comp ddp_comp)
> +{
> + struct mtk_drm_private *private = drm->dev_private;
> + unsigned int ret;
> +
> + if (mtk_drm_find_comp_in_ddp(ddp_comp, private->data->main_path,
> + private->data->main_len) == true) {
' == true' is redundant, so remove it.
> + ret = BIT(0);
> + } else if (mtk_drm_find_comp_in_ddp(ddp_comp,
> + private->data->ext_path,
> + private->data->ext_len) == true) {
Ditto.
> + ret = BIT(1);
> + } else if (mtk_drm_find_comp_in_ddp(ddp_comp,
> + private->data->third_path,
> + private->data->third_len) == true) {
Ditto.
> + ret = BIT(2);
> + } else {
> + DRM_INFO("Failed to find comp in ddp table\n");
> + ret = 0;
> + }
> + return ret;
> +}
> +
> int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> struct mtk_ddp_comp *comp, enum mtk_ddp_comp_id comp_id,
> const struct mtk_ddp_comp_funcs *funcs)
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index debe36395fe7..1d9e00b69462 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -202,6 +202,8 @@ static inline void mtk_ddp_ctm_set(struct mtk_ddp_comp
> *comp,
>
> int mtk_ddp_comp_get_id(struct device_node *node,
> enum mtk_ddp_comp_type comp_type);
> +unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
> + struct mtk_ddp_comp ddp_comp);
> int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,
> struct mtk_ddp_comp *comp, enum mtk_ddp_comp_id comp_id,
> const struct mtk_ddp_comp_funcs *funcs);
> --
> 2.25.1
>
[PATCH mmotm] tmpfs: support 64-bit inums per-sb fix
Expanded Chris's Documentation and Kconfig help on tmpfs inode64. TMPFS_INODE64 still there, still default N, but writing down its very limited limitation does make me wonder again if we want the option. Signed-off-by: Hugh Dickins --- Andrew, please fold into tmpfs-support-64-bit-inums-per-sb.patch later. Randy, you're very active on Documentation and linux-next: may I ask you please to try applying this patch to latest, and see if tmpfs.rst comes out looking right to you? I'm an old dog still stuck in the days of tmpfs.txt, hoping to avoid new tricks for a while. Thanks! (Bonus points if you can explain what the "::" on line 122 is about. I started out reading Documentation/doc-guide/sphinx.rst, but... got diverted. Perhaps I should ask Mauro or Jon, but turning for help first to you.) Documentation/filesystems/tmpfs.rst | 13 ++--- fs/Kconfig | 16 +++- 2 files changed, 21 insertions(+), 8 deletions(-) --- mmotm/Documentation/filesystems/tmpfs.rst 2020-07-27 18:54:51.116524795 -0700 +++ linux/Documentation/filesystems/tmpfs.rst 2020-08-01 18:37:07.719713987 -0700 @@ -153,11 +153,18 @@ parameters with chmod(1), chown(1) and c tmpfs has a mount option to select whether it will wrap at 32- or 64-bit inode numbers: +=== inode64 Use 64-bit inode numbers inode32 Use 32-bit inode numbers +=== + +On a 32-bit kernel, inode32 is implicit, and inode64 is refused at mount time. +On a 64-bit kernel, CONFIG_TMPFS_INODE64 sets the default. inode64 avoids the +possibility of multiple files with the same inode number on a single device; +but risks glibc failing with EOVERFLOW once 33-bit inode numbers are reached - +if a long-lived tmpfs is accessed by 32-bit applications so ancient that +opening a file larger than 2GiB fails with EINVAL. -On 64-bit, the default is set by CONFIG_TMPFS_INODE64. On 32-bit, inode64 is -not legal and will produce an error at mount time. So 'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs' will give you tmpfs instance on /mytmpfs which can allocate 10GB @@ -170,5 +177,5 @@ RAM/SWAP in 10240 inodes and it is only Hugh Dickins, 4 June 2007 :Updated: KOSAKI Motohiro, 16 Mar 2010 -Updated: +:Updated: Chris Down, 13 July 2020 --- mmotm/fs/Kconfig2020-07-27 18:54:59.384550639 -0700 +++ linux/fs/Kconfig2020-08-01 18:11:33.749236321 -0700 @@ -223,12 +223,18 @@ config TMPFS_INODE64 default n help tmpfs has historically used only inode numbers as wide as an unsigned - int. In some cases this can cause wraparound, potentially resulting in - multiple files with the same inode number on a single device. This option - makes tmpfs use the full width of ino_t by default, similarly to the - inode64 mount option. + int. In some cases this can cause wraparound, potentially resulting + in multiple files with the same inode number on a single device. This + option makes tmpfs use the full width of ino_t by default, without + needing to specify the inode64 option when mounting. - To override this default, use the inode32 or inode64 mount options. + But if a long-lived tmpfs is to be accessed by 32-bit applications so + ancient that opening a file larger than 2GiB fails with EINVAL, then + the INODE64 config option and inode64 mount option risk operations + failing with EOVERFLOW once 33-bit inode numbers are reached. + + To override this configured default, use the inode32 or inode64 + option when mounting. If unsure, say N.
Re: [PATCH v6 08/22] bootconfig: init: Allow admin to use bootconfig for init command line
On Fri, Feb 07, 2020 at 02:46:03PM -0500, Steven Rostedt wrote:
>
> diff --git a/init/main.c b/init/main.c
> index 491f1cdb3105..113c8244e5f0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -142,6 +142,15 @@ static char *extra_command_line;
> /* Extra init arguments */
> static char *extra_init_args;
>
> +#ifdef CONFIG_BOOT_CONFIG
> +/* Is bootconfig on command line? */
> +static bool bootconfig_found;
> +static bool initargs_found;
> +#else
> +# define bootconfig_found false
> +# define initargs_found false
> +#endif
> +
> static char *execute_command;
> static char *ramdisk_execute_command;
>
> @@ -336,17 +345,32 @@ u32 boot_config_checksum(unsigned char *p, u32 size)
> return ret;
> }
>
> +static int __init bootconfig_params(char *param, char *val,
> + const char *unused, void *arg)
> +{
> + if (strcmp(param, "bootconfig") == 0) {
> + bootconfig_found = true;
> + } else if (strcmp(param, "--") == 0) {
> + initargs_found = true;
> + }
> + return 0;
> +}
> +
I came across this as I was poking around some of the command line
parsing. AFAICT, initargs_found will never be set to true here, because
parse_args handles "--" itself by immediately returning: it doesn't
invoke the callback for it. So you'd instead have to check the return of
parse_args("bootconfig"...) to detect the initargs_found case.
> static void __init setup_boot_config(const char *cmdline)
> {
> + static char tmp_cmdline[COMMAND_LINE_SIZE] __initdata;
> u32 size, csum;
> char *data, *copy;
> const char *p;
> u32 *hdr;
> int ret;
>
> - p = strstr(cmdline, "bootconfig");
> - if (!p || (p != cmdline && !isspace(*(p-1))) ||
> - (p[10] && !isspace(p[10])))
> + /* All fall through to do_early_param. */
> + strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> + parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
> +bootconfig_params);
> +
> + if (!bootconfig_found)
> return;
Re: [PATCH v2] ASoC: fsl-asoc-card: Remove fsl_asoc_card_set_bias_level function
On Sat, Aug 1, 2020 at 4:01 PM Nicolin Chen wrote:
>
> Hi,
>
> Having two nits and one question, inline:
>
> On Thu, Jul 30, 2020 at 05:47:02PM +0800, Shengjiu Wang wrote:
> > @@ -182,6 +180,69 @@ static int fsl_asoc_card_hw_params(struct
> > snd_pcm_substream *substream,
> > cpu_priv->slot_width);
> > if (ret && ret != -ENOTSUPP) {
> > dev_err(dev, "failed to set TDM slot for cpu dai\n");
> > + goto out;
> > + }
> > + }
> > +
> > + /* Specific configuration for PLL */
> > + if (codec_priv->pll_id && codec_priv->fll_id) {
> > + if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE)
> > + pll_out = priv->sample_rate * 384;
> > + else
> > + pll_out = priv->sample_rate * 256;
> > +
> > + ret = snd_soc_dai_set_pll(asoc_rtd_to_codec(rtd, 0),
> > + codec_priv->pll_id,
> > + codec_priv->mclk_id,
> > + codec_priv->mclk_freq, pll_out);
> > + if (ret) {
> > + dev_err(dev, "failed to start FLL: %d\n", ret);
> > + goto out;
> > + }
> > +
> > + ret = snd_soc_dai_set_sysclk(asoc_rtd_to_codec(rtd, 0),
> > + codec_priv->fll_id,
> > + pll_out, SND_SOC_CLOCK_IN);
>
> Just came into my mind: do we need some protection here to prevent
> PLL/SYSCLK reconfiguration if TX/RX end up with different values?
>
Sorry, not really catching your point. could you please elaborate?
Why do TX/RX end up with different values?
best regards
wang shengiu
> > + return 0;
> > +
> > +out:
> > + priv->streams &= ~BIT(substream->stream);
> > + return ret;
>
> Rather than "out:" which doesn't explicitly indicate an error-out,
> "fail:" would be better, following what we used in probe().
>
> > +static int fsl_asoc_card_hw_free(struct snd_pcm_substream *substream)
> > +{
> > + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > + struct fsl_asoc_card_priv *priv = snd_soc_card_get_drvdata(rtd->card);
> > + struct codec_priv *codec_priv = &priv->codec_priv;
> > + struct device *dev = rtd->card->dev;
> > + int ret;
> > +
> > + priv->streams &= ~BIT(substream->stream);
> > +
>
> > + if (!priv->streams && codec_priv->pll_id &&
> > + codec_priv->fll_id) {
>
> This now can fit into single line :)
arch/mips/sgi-ip30/ip30-setup.c:122:13: warning: no previous prototype for 'plat_mem_setup'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d52daa8620c65960e1ef882adc1f92061326bd7a
commit: 7505576d1c1ac0cfe85fdf90999433dd8b673012 MIPS: add support for SGI
Octane (IP30)
date: 9 months ago
config: mips-randconfig-r014-20200802 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7505576d1c1ac0cfe85fdf90999433dd8b673012
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> arch/mips/sgi-ip30/ip30-setup.c:122:13: warning: no previous prototype for
>> 'plat_mem_setup' [-Wmissing-prototypes]
122 | void __init plat_mem_setup(void)
| ^~
vim +/plat_mem_setup +122 arch/mips/sgi-ip30/ip30-setup.c
118
119 /**
120 * plat_mem_setup - despite the name, misc setup happens here.
121 */
> 122 void __init plat_mem_setup(void)
123 {
124 ip30_mem_init();
125
126 /* XXX: Hard lock on /sbin/init if this flag isn't specified. */
127 prom_flags |= PROM_FLAG_DONT_FREE_TEMP;
128
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [GIT] Networking
From: Linus Torvalds Date: Sat, 1 Aug 2020 16:45:49 -0700 > On Sat, Aug 1, 2020 at 2:36 PM David Miller wrote: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git > > How is this wrt an rc8 or a final? Nothing scary in there, I think you can safely do a -final with those networking changes. > On a very much related note, I really wish you didn't send the > networking fixes the day before a release is scheduled. > > If it's really quiet., send them on (say) Wed/Thu. And then on > Saturday, send a note saying "no, important stuff", hold on. Or say > "nothing new". > > Because right now the "last-minute network pull request" has become a > pattern, and I have a very hard time judging whether I should delay a > release for it. Sorry about that, just the way things work during the week I can't catch my breath until late Friday night or Saturday usually to review what I have and send a pull request to you. I'll shoot for more mid-week pulls in the future.
Re: [PATCH] staging: rts5208: clear alignment style issues
On Sun, 2020-08-02 at 00:00 +0300, Tomer Samara wrote:
> Clear checkpatch alignment style issues in rtsx_transport.c.
> CHECK: Alignment should match open parenthesis
[]
> diff --git a/drivers/staging/rts5208/rtsx_transport.c
> b/drivers/staging/rts5208/rtsx_transport.c
[]
> @@ -678,7 +678,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8
> card, void *buf,
>
> /* Wait for TRANS_OK_INT */
> timeleft = wait_for_completion_interruptible_timeout(&trans_done,
> - msecs_to_jiffies(timeout));
> +
> msecs_to_jiffies(timeout));
> if (timeleft <= 0) {
> dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
> __func__, __LINE__);
Always try to improve the code rather than just
shut up checkpatch warnings.
Perhaps it's more sensible to centralize the uses of
wait_for_completion_interruptible_timeout.
Something like:
---
drivers/staging/rts5208/rtsx_transport.c | 36 +---
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_transport.c
b/drivers/staging/rts5208/rtsx_transport.c
index 5f1eefe80f1e..269ff1be7cba 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -222,12 +222,18 @@ void rtsx_send_cmd_no_wait(struct rtsx_chip *chip)
rtsx_writel(chip, RTSX_HCBCTLR, val);
}
+static inline bool rtsx_wait(struct completion *comp, int timeout)
+{
+ unsigned long t = msecs_to_jiffies(timeout);
+
+ return wait_for_completion_interruptible_timeout(comp, t) > 0;
+}
+
int rtsx_send_cmd(struct rtsx_chip *chip, u8 card, int timeout)
{
struct rtsx_dev *rtsx = chip->rtsx;
struct completion trans_done;
u32 val = BIT(31);
- long timeleft;
int err = 0;
if (card == SD_CARD)
@@ -257,9 +263,8 @@ int rtsx_send_cmd(struct rtsx_chip *chip, u8 card, int
timeout)
spin_unlock_irq(&rtsx->reg_lock);
/* Wait for TRANS_OK_INT */
- timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, msecs_to_jiffies(timeout));
- if (timeleft <= 0) {
+
+ if (!rtsx_wait(&trans_done, timeout)) {
dev_dbg(rtsx_dev(chip), "chip->int_reg = 0x%x\n",
chip->int_reg);
err = -ETIMEDOUT;
@@ -322,7 +327,6 @@ static int rtsx_transfer_sglist_adma_partial(struct
rtsx_chip *chip, u8 card,
u8 dir;
int sg_cnt, i, resid;
int err = 0;
- long timeleft;
struct scatterlist *sg_ptr;
u32 val = TRIG_DMA;
@@ -419,9 +423,7 @@ static int rtsx_transfer_sglist_adma_partial(struct
rtsx_chip *chip, u8 card,
spin_unlock_irq(&rtsx->reg_lock);
- timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, msecs_to_jiffies(timeout));
- if (timeleft <= 0) {
+ if (!rtsx_wait(&trans_done, timeout)) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
dev_dbg(rtsx_dev(chip), "chip->int_reg = 0x%x\n",
@@ -443,9 +445,7 @@ static int rtsx_transfer_sglist_adma_partial(struct
rtsx_chip *chip, u8 card,
if (rtsx->trans_result == TRANS_NOT_READY) {
init_completion(&trans_done);
spin_unlock_irq(&rtsx->reg_lock);
- timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, msecs_to_jiffies(timeout));
- if (timeleft <= 0) {
+ if (!rtsx_wait(&trans_done, timeout)) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
dev_dbg(rtsx_dev(chip), "chip->int_reg = 0x%x\n",
@@ -486,7 +486,6 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip
*chip, u8 card,
u8 dir;
int buf_cnt, i;
int err = 0;
- long timeleft;
struct scatterlist *sg_ptr;
if (!sg || (num_sg <= 0))
@@ -563,9 +562,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip
*chip, u8 card,
spin_unlock_irq(&rtsx->reg_lock);
- timeleft = wait_for_completion_interruptible_timeout(
- &trans_done, msecs_to_jiffies(timeout));
- if (timeleft <= 0) {
+ if (!rtsx_wait(&trans_done, timeout)) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
dev_dbg(rtsx_dev(chip), "chip->int_reg = 0x%x\n",
@@ -590,9 +587,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip
*chip, u8 card,
if (rtsx->trans_result == TRANS_NOT_READY) {
init_completion(&trans_done);
spin_unlock_irq(&rtsx->reg_lock);
- timeleft = wait_for_completion_interruptible_timeout(
-
drivers/net/ethernet/nxp/lpc_eth.c:561:35: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d52daa8620c65960e1ef882adc1f92061326bd7a commit: 35974a7cc23c5deb5597c0a42183172498c4a0a8 net: lpc-enet: allow compile testing date: 12 months ago config: nios2-randconfig-s031-20200802 (attached as .config) compiler: nios2-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-115-g5fc204f2-dirty git checkout 35974a7cc23c5deb5597c0a42183172498c4a0a8 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=nios2 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/net/ethernet/nxp/lpc_eth.c:561:35: sparse: sparse: incorrect type in >> assignment (different base types) @@ expected restricted __le32 >> [usertype] packet @@ got unsigned int @@ >> drivers/net/ethernet/nxp/lpc_eth.c:561:35: sparse: expected restricted >> __le32 [usertype] packet >> drivers/net/ethernet/nxp/lpc_eth.c:561:35: sparse: got unsigned int drivers/net/ethernet/nxp/lpc_eth.c:572:35: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] packet @@ got unsigned int @@ drivers/net/ethernet/nxp/lpc_eth.c:572:35: sparse: expected restricted __le32 [usertype] packet drivers/net/ethernet/nxp/lpc_eth.c:572:35: sparse: got unsigned int >> drivers/net/ethernet/nxp/lpc_eth.c:574:36: sparse: sparse: incorrect type in >> assignment (different base types) @@ expected restricted __le32 >> [usertype] control @@ got int @@ >> drivers/net/ethernet/nxp/lpc_eth.c:574:36: sparse: expected restricted >> __le32 [usertype] control >> drivers/net/ethernet/nxp/lpc_eth.c:574:36: sparse: got int >> drivers/net/ethernet/nxp/lpc_eth.c:900:31: sparse: sparse: restricted __le32 >> degrades to integer >> drivers/net/ethernet/nxp/lpc_eth.c:903:23: sparse: sparse: incorrect type in >> assignment (different base types) @@ expected unsigned int [usertype] >> ethst @@ got restricted __le32 [usertype] statusinfo @@ >> drivers/net/ethernet/nxp/lpc_eth.c:903:23: sparse: expected unsigned int >> [usertype] ethst >> drivers/net/ethernet/nxp/lpc_eth.c:903:23: sparse: got restricted __le32 >> [usertype] statusinfo >> drivers/net/ethernet/nxp/lpc_eth.c:909:41: sparse: sparse: incorrect type in >> initializer (different base types) @@ expected int si @@ got >> restricted __le32 [usertype] statusinfo @@ >> drivers/net/ethernet/nxp/lpc_eth.c:909:41: sparse: expected int si drivers/net/ethernet/nxp/lpc_eth.c:909:41: sparse: got restricted __le32 [usertype] statusinfo >> drivers/net/ethernet/nxp/lpc_eth.c:1051:28: sparse: sparse: incorrect type >> in assignment (different base types) @@ expected restricted __le32 >> [usertype] control @@ got unsigned int @@ drivers/net/ethernet/nxp/lpc_eth.c:1051:28: sparse: expected restricted __le32 [usertype] control drivers/net/ethernet/nxp/lpc_eth.c:1051:28: sparse: got unsigned int drivers/net/ethernet/nxp/lpc_eth.c:1308:42: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] **mapbase @@ got void ** @@ drivers/net/ethernet/nxp/lpc_eth.c:1308:42: sparse: expected void [noderef] **mapbase >> drivers/net/ethernet/nxp/lpc_eth.c:1308:42: sparse: got void ** drivers/net/ethernet/nxp/lpc_eth.c: note: in included file (through arch/nios2/include/asm/io.h, include/linux/io.h, arch/nios2/include/asm/pgtable.h, ...): include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] in
Re: [PATCH v2] drivers/net/wan/lapbether: Use needed_headroom instead of hard_header_len
On Sat, Aug 1, 2020 at 6:31 AM Willem de Bruijn wrote: > > The kernel interface cannot be changed. If packet sockets used to pass > the first byte up to userspace, they have to continue to do so. > > So I think you can limit the header_ops to only dev_hard_header. Actually if we want to keep the kernel interface unchanged, we shouldn't implement header_ops for dev_hard_header either, because this changes the way the user space program sends DGRAM packets, too. Before the change the userspace program needs to add the 1-byte header before sending, and after the change the userspace program will let the kernel add the header via dev_hard_header. > Fixes should be small and targeted. Any larger refactoring is > best addressed in a separate net-next patch. I guess the best way for this fix patch would be just add a 0-byte packet check before the driver reads skb->data[0]. Thanks! I'll add the check and re-send the patch.
[tip:x86/entry] BUILD SUCCESS adb334d17858d8b679a41f7f2cd230e5c6accc0a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry branch HEAD: adb334d17858d8b679a41f7f2cd230e5c6accc0a Merge branch 'WIP.x86/entry' into x86/entry, to merge the latest generic code and resolve conflicts elapsed time: 2148m configs tested: 85 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig xtensaxip_kc705_defconfig arm versatile_defconfig arm ezx_defconfig powerpc maple_defconfig armpleb_defconfig armmmp2_defconfig arm lpd270_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200731 i386 randconfig-a004-20200731 i386 randconfig-a006-20200731 i386 randconfig-a002-20200731 i386 randconfig-a001-20200731 i386 randconfig-a003-20200731 i386 randconfig-a004-20200802 i386 randconfig-a005-20200802 i386 randconfig-a001-20200802 i386 randconfig-a002-20200802 i386 randconfig-a003-20200802 i386 randconfig-a006-20200802 i386 randconfig-a004-20200801 i386 randconfig-a005-20200801 i386 randconfig-a001-20200801 i386 randconfig-a003-20200801 i386 randconfig-a002-20200801 i386 randconfig-a006-20200801 x86_64 randconfig-a015-20200731 x86_64 randconfig-a014-20200731 x86_64 randconfig-a016-20200731 x86_64 randconfig-a012-20200731 x86_64 randconfig-a013-20200731 x86_64 randconfig-a011-20200731 i386 randconfig-a016-20200731 i386 randconfig-a012-20200731 i386 randconfig-a014-20200731 i386 randconfig-a015-20200731 i386 randconfig-a013-20200731 i386 randconfig-a011-20200731 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v5] PCI/ACS: Enable PCI_ACS_TB and disable only when needed for ATS
Hi Bjorn,
On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
>
> On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
> >
> > The ACS "Translation Blocking" bit blocks the translated addresses from
> > the devices. We don't expect such traffic from devices unless ATS is
> > enabled on them. A device sending such traffic without ATS enabled,
> > indicates malicious intent, and thus should be blocked.
> >
> > Enable PCI_ACS_TB by default for all devices, and it stays enabled until
> > atleast one of the devices downstream wants to enable ATS. It gets
> > disabled to enable ATS on a device downstream it, and then gets enabled
> > back on once all the downstream devices don't need ATS.
> >
> > Signed-off-by: Rajat Jain
Just checking to see if you got a chance to look at this V5 patch.
Thanks & Best Regards,
Rajat
> > ---
> > Note that I'm ignoring the devices that require quirks to enable or
> > disable ACS, instead of using the standard way for ACS configuration.
> > The reason is that it would require adding yet another quirk table or
> > quirk function pointer, that I don't know how to implement for those
> > devices, and will neither have the devices to test that code.
> >
> > v5: Enable TB and disable ATS for all devices on boot. Disable TB later
> > only if needed to enable ATS on downstream devices.
> > v4: Add braces to avoid warning from kernel robot
> > print warning for only external-facing devices.
> > v3: print warning if ACS_TB not supported on external-facing/untrusted
> > ports.
> > Minor code comments fixes.
> > v2: Commit log change
> >
> > drivers/pci/ats.c | 5
> > drivers/pci/pci.c | 57 +
> > drivers/pci/pci.h | 2 ++
> > drivers/pci/probe.c | 2 +-
> > include/linux/pci.h | 2 ++
> > 5 files changed, 67 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> > index b761c1f72f67..e2ea9083f30f 100644
> > --- a/drivers/pci/ats.c
> > +++ b/drivers/pci/ats.c
> > @@ -28,6 +28,9 @@ void pci_ats_init(struct pci_dev *dev)
> > return;
> >
> > dev->ats_cap = pos;
> > +
> > + dev->ats_enabled = 1; /* To avoid WARN_ON from pci_disable_ats() */
> > + pci_disable_ats(dev);
> > }
> >
> > /**
> > @@ -82,6 +85,7 @@ int pci_enable_ats(struct pci_dev *dev, int ps)
> > }
> > pci_write_config_word(dev, dev->ats_cap + PCI_ATS_CTRL, ctrl);
> >
> > + pci_disable_acs_trans_blocking(dev);
> > dev->ats_enabled = 1;
> > return 0;
> > }
> > @@ -102,6 +106,7 @@ void pci_disable_ats(struct pci_dev *dev)
> > ctrl &= ~PCI_ATS_CTRL_ENABLE;
> > pci_write_config_word(dev, dev->ats_cap + PCI_ATS_CTRL, ctrl);
> >
> > + pci_enable_acs_trans_blocking(dev);
> > dev->ats_enabled = 0;
> > }
> > EXPORT_SYMBOL_GPL(pci_disable_ats);
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 73a862782214..614e3c1e8c56 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -876,6 +876,9 @@ static void pci_std_enable_acs(struct pci_dev *dev)
> > /* Upstream Forwarding */
> > ctrl |= (cap & PCI_ACS_UF);
> >
> > + /* Translation Blocking */
> > + ctrl |= (cap & PCI_ACS_TB);
> > +
> > pci_write_config_word(dev, pos + PCI_ACS_CTRL, ctrl);
> > }
> >
> > @@ -904,6 +907,60 @@ static void pci_enable_acs(struct pci_dev *dev)
> > pci_disable_acs_redir(dev);
> > }
> >
> > +void pci_disable_acs_trans_blocking(struct pci_dev *pdev)
> > +{
> > + u16 cap, ctrl, pos;
> > + struct pci_dev *dev;
> > +
> > + if (!pci_acs_enable)
> > + return;
> > +
> > + for (dev = pdev; dev; dev = pci_upstream_bridge(pdev)) {
> > +
> > + pos = dev->acs_cap;
> > + if (!pos)
> > + continue;
> > +
> > + /*
> > +* Disable translation blocking when first downstream
> > +* device that needs it (for ATS) wants to enable ATS
> > +*/
> > + if (++dev->ats_dependencies == 1) {
>
> I am a little worried about a potential race condition here. I know
> that 2 PCI devices cannot be enumerating at the same time. Do we know
> if multiple pci_enable_ats() and pci_disable_ats() function calls can
> be simultaneously executing (even for different devices)? If so, we
> may need an atomic_t variable for ats_dependencies.
>
> Thanks,
>
> Rajat
>
>
> > + pci_read_config_word(dev, pos + PCI_ACS_CAP, &cap);
> > + pci_read_config_word(dev, pos + PCI_ACS_CTRL,
> > &ctrl);
> > + ctrl &= ~(cap & PCI_ACS_TB);
> > + pci_write_config_word(dev, pos + PCI_ACS_CTRL,
> > ctrl);
> > + }
> > + }
> > +}
> > +
> > +void pci_enable_acs_trans_blocking(struct pci_dev *pdev)
> > +{
> > + u16 cap, ctrl, pos;
> > + struct pci_dev *dev;
> > +
> > +
Re: [PATCH v2 2/5] drm/mediatek: fix boot up for 720 and 480 but 1080
Hi, Frank:
Frank Wunderlich 於 2020年7月28日 週二 下午7:19寫道：
>
> From: chunhui dai
>
> - disable tmds on phy on mt2701
> - support other resolutions like 1280x1024
If this patch does two things, it should be broken into two patches.
>
> without this Patch i see flickering on my TFT (1280x1024),
> so i guess clock is wrong.
>
> Signed-off-by: chunhui dai
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank Wunderlich
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 3 +++
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
> 3 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 5223498502c4..edadb7a700f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -184,6 +184,9 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> return PTR_ERR(phy_provider);
> }
>
> + if (hdmi_phy->conf->pll_default_off)
> + hdmi_phy->conf->hdmi_phy_disable_tmds(hdmi_phy);
I think every pll is default off, so you should turn on pll rather
than disable tmds.
Regards,
Chun-Kuang.
> +
> return of_clk_add_provider(dev->of_node, of_clk_src_simple_get,
>hdmi_phy->pll);
> }
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index 2d8b3182470d..f472fdeb63dc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -22,6 +22,7 @@ struct mtk_hdmi_phy;
> struct mtk_hdmi_phy_conf {
> bool tz_disabled;
> unsigned long flags;
> + bool pll_default_off;
> const struct clk_ops *hdmi_phy_clk_ops;
> void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index d3cc4022e988..6fbedacfc1e8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -239,6 +239,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
> *hdmi_phy)
> struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
> .tz_disabled = true,
> .flags = CLK_SET_RATE_GATE,
> + .pll_default_off = true,
> .hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
> .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
> .hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
> --
> 2.25.1
>
Re: [PATCH v2 1/5] drm/mediatek: config component output by device node port
Hi, Frank:
Frank Wunderlich 於 2020年7月28日 週二 下午7:18寫道：
>
> From: Bibby Hsieh
>
> We can select output component by decive node port.
> Main path default output component is DSI.
> External path default output component is DPI.
>
> without this Patch i get this warning:
>
> WARNING: CPU: 3 PID: 70 at drivers/gpu/drm/drm_mode_config.c:621
> drm_mode_config_validate+0x1d8/0x258
>
> Signed-off-by: Bibby Hsieh
>
> added small fixes for warnings
>
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank Wunderlich
> ---
[snip]
>
> -static const enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
> +static enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_COLOR1,
> DDP_COMPONENT_GAMMA,
> @@ -459,6 +466,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
>
> /* Iterate over sibling DISP function blocks */
> for_each_child_of_node(phandle->parent, node) {
> + struct device_node *port, *ep, *remote;
> const struct of_device_id *of_id;
> enum mtk_ddp_comp_type comp_type;
> int comp_id;
> @@ -522,6 +530,32 @@ static int mtk_drm_probe(struct platform_device *pdev)
>
> private->ddp_comp[comp_id] = comp;
> }
> +
> + if (comp_type != MTK_DSI && comp_type != MTK_DPI) {
> + port = of_graph_get_port_by_id(node, 0);
> + if (!port)
> + continue;
> + ep = of_get_child_by_name(port, "endpoint");
> + of_node_put(port);
> + if (!ep)
> + continue;
> + remote = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!remote)
> + continue;
> + of_id = of_match_node(mtk_ddp_comp_dt_ids, remote);
> + if (!of_id)
> + continue;
> + comp_type = (enum mtk_ddp_comp_type)of_id->data;
> + for (i = 0; i < private->data->main_len - 1; i++)
> + if (private->data->main_path[i] == comp_id)
> + private->data->main_path[i + 1] =
> + mtk_ddp_comp_get_id(node, comp_type);
> + for (i = 0; i < private->data->ext_len - 1; i++)
> + if (private->data->ext_path[i] == comp_id)
> + private->data->ext_path[i + 1] =
> + mtk_ddp_comp_get_id(node, comp_type);
> + }
The port property is not defined in binding document [1], so define it
in binding document first.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt?h=v5.8-rc7
Regards,
Chun-Kuang.
> }
>
> if (!private->mutex_node) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index b5be63e53176..7fcaab648bf1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -21,9 +21,9 @@ struct drm_property;
> struct regmap;
>
> struct mtk_mmsys_driver_data {
> - const enum mtk_ddp_comp_id *main_path;
> + enum mtk_ddp_comp_id *main_path;
> unsigned int main_len;
> - const enum mtk_ddp_comp_id *ext_path;
> + enum mtk_ddp_comp_id *ext_path;
> unsigned int ext_len;
> const enum mtk_ddp_comp_id *third_path;
> unsigned int third_len;
> --
> 2.25.1
>
Re: [GIT PULL] Fourth batch of perf tooling fixes for v5.8
The pull request you sent on Sat, 1 Aug 2020 16:06:18 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-tools-fixes-2020-08-01 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bf121a0bda29daa67a1fcedbdf479f6b03c9f977 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] thread fix v5.8-rc8
The pull request you sent on Sat, 1 Aug 2020 23:05:52 +0200: > g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux > tags/for-linus-2020-08-01 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0ae3495b6502cf93634cbd027cb2f6f9f83a406f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT] Networking
The pull request you sent on Sat, 01 Aug 2020 14:36:31 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ac3a0c8472969a03c0496ae774b3a29eb26c8d5a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v4 2/2] soc: mediatek: add mtk-devapc driver
Hi, Neal:
Neal Liu 於 2020年7月29日 週三 下午4:29寫道：
>
> MediaTek bus fabric provides TrustZone security support and data
> protection to prevent slaves from being accessed by unexpected
> masters.
> The security violation is logged and sent to the processor for
> further analysis or countermeasures.
>
> Any occurrence of security violation would raise an interrupt, and
> it will be handled by mtk-devapc driver. The violation
> information is printed in order to find the murderer.
>
> Signed-off-by: Neal Liu
> ---
[snip]
> +
> +struct mtk_devapc_context {
> + struct device *dev;
> + u32 vio_idx_num;
> + void __iomem *devapc_pd_base;
This is devapc context, so prefix 'devapc' is redundant.
And, what does 'pd' mean?
Regards,
Chun-Kuang.
> + struct mtk_devapc_vio_info *vio_info;
> + const struct mtk_devapc_pd_offset *offset;
> + const struct mtk_devapc_vio_dbgs *vio_dbgs;
> +};
> +
Re: [GIT] Networking
On Sat, Aug 1, 2020 at 2:36 PM David Miller wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git How is this wrt an rc8 or a final? I have another possible small reason to do an rc8 right now. And this roughly doubles my current diff. On a very much related note, I really wish you didn't send the networking fixes the day before a release is scheduled. If it's really quiet., send them on (say) Wed/Thu. And then on Saturday, send a note saying "no, important stuff", hold on. Or say "nothing new". Because right now the "last-minute network pull request" has become a pattern, and I have a very hard time judging whether I should delay a release for it. Linus
Re: exfatprogs-1.0.4 version released
2020-07-31 18:56 GMT+09:00, Sedat Dilek : > On Fri, Jul 31, 2020 at 9:16 AM Namjae Jeon > wrote: >> >> Hi folk, >> >> In this release, The performance of fsck have been much improved and >> the new option in mkfs have been added to adjust boundary alignment. >> >> As the result below, The fsck performance is improved close to windows's >> fsck >> and much faster than the one in exfat-utils package. >> >> We measured the performance on Samsung 64GB Pro microSDXC UHS-I Class 10 >> which >> was filled up to 35GB with 9948 directories and 16506 files. >> >> | Implementation | version | execution time (seconds) | >> |- |---|--| >> | **exfatprogs fsck** | 1.0.4 | 11.561 | >> | Windows fsck | Windows 10 1809 | 11.449 | >> | [exfat-fuse fsck]| 1.3.0 | 68.977 | >> > > Hi Namjae Jeon (what is your First name and Family name?), Hi Sedat, First name : Namjae, Last name : Jeon > > congrats to version 1.0.4 and hope to see it in the Debian repositories > soon. Thanks:) > > Great numbers for exfatprogs/fsck! > >> And we have been preparing to add fsck repair feature in the next >> version. >> Any feedback is welcome!:) >> >> CHANGES : >> * fsck.exfat: display sector, cluster, and volume sizes in the human >>readable format. >> * fsck.exfat: reduce the elapsed time using read-ahead. >> >> NEW FEATURES : >> * mkfs.exfat: generate pseudo unique serials while creating filesystems. >> * mkfs.exfat: add the "-b" option to align the start offset of FAT and >>data clusters. >> * fsck.exfat: repair zero-byte files which have the NoFatChain >> attribute. >> >> BUG FIXES : >> * Fix memory leaks on error handling paths. >> * fsck.exfat: fix the bug that cannot access space beyond 2TB. >> >> The git tree is at: >> https://github.com/exfatprogs/exfatprogs >> >> The tarballs can be found at: >> >> https://github.com/exfatprogs/exfatprogs/releases/download/1.0.4/exfatprogs-1.0.4.tar.gz >> > > Just a small nit for the next announcement. > Please point (also) to the tar.xz tarball and maybe to the releases > tag in GitHub. Sure. I will do that on next release. > ( Today, I love/prefer to use ZSTD where possible - that is another story. > ) I'm not sure if it is meaningful to provide various compression for small archive file. In particular, I wonder if other distribution maintainers want it. > > Have more fun. Nice day! > > Regards, > - Sedat - > > [1] > https://github.com/exfatprogs/exfatprogs/releases/download/1.0.4/exfatprogs-1.0.4.tar.xz > [2] https://github.com/exfatprogs/exfatprogs/releases/tag/1.0.4 >
Re: [PATCH v4 2/2] cpufreq: intel_pstate: Implement passive mode with HWP enabled
On Tue, 2020-07-28 at 17:13 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Allow intel_pstate to work in the passive mode with HWP enabled and
> make it set the HWP minimum performance limit (HWP floor) to the
> P-state value given by the target frequency supplied by the cpufreq
> governor, so as to prevent the HWP algorithm and the CPU scheduler
> from working against each other, at least when the schedutil governor
> is in use, and update the intel_pstate documentation accordingly.
>
> Among other things, this allows utilization clamps to be taken
> into account, at least to a certain extent, when intel_pstate is
> in use and makes it more likely that sufficient capacity for
> deadline tasks will be provided.
>
> After this change, the resulting behavior of an HWP system with
> intel_pstate in the passive mode should be close to the behavior
> of the analogous non-HWP system with intel_pstate in the passive
> mode, except that in the frequency range below the base frequency
> (ie. the frequency retured by the base_frequency cpufreq attribute
> in sysfs on HWP systems) the HWP algorithm is allowed to go above
> the floor P-state set by intel_pstate with or without hardware
> coordination of P-states among CPUs in the same package.
>
Do you mean HWP.req.min will be below base_freq (unless user overrides
it)?
With busy workload I see HWP req.min = HWP req.max.
The base freq: 1.3GHz (ratio 0x0d), MAX 1C turbo: 3.9GHz (ratio: 0x27)
When I monitor MSR 0x774 (HWP_REQ), I see
0x80002727
Normally msr 0x774
0x80002704
Thanks,
Srinivas
> Also note that the setting of the HWP floor may not be taken into
> account by the processor in the following cases:
>
> * For the HWP floor in the range of P-states above the base
>frequency, referred to as the turbo range, the processor has a
>license to choose any P-state from that range, either below or
>above the HWP floor, just like a non-HWP processor in the case
>when the target P-state falls into the turbo range.
>
> * If P-states of the CPUs in the same package are coordinated
>at the hardware level, the processor may choose a P-state
>above the HWP floor, just like a non-HWP processor in the
>analogous case.
>
> With this change applied, intel_pstate in the passive mode
> assumes complete control over the HWP request MSR and concurrent
> changes of that MSR (eg. via the direct MSR access interface) are
> overridden by it.
>
> Signed-off-by: Rafael J. Wysocki
> ---
>
> v1 -> v2:
>* Avoid a race condition when updating the HWP request register
> while
> setting a new EPP value via sysfs.
>
> v2 -> v3:
>* Rebase.
>
> v3 -> v4:
>* Avoid exposing the hwp_dynamic_boost sysfs switch in the passive
> mode.
>
> ---
> Documentation/admin-guide/pm/intel_pstate.rst | 89 +--
> drivers/cpufreq/intel_pstate.c| 204
> --
> 2 files changed, 204 insertions(+), 89 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -36,6 +36,7 @@
> #define INTEL_PSTATE_SAMPLING_INTERVAL (10 * NSEC_PER_MSEC)
>
> #define INTEL_CPUFREQ_TRANSITION_LATENCY 2
> +#define INTEL_CPUFREQ_TRANSITION_DELAY_HWP 5000
> #define INTEL_CPUFREQ_TRANSITION_DELAY 500
>
> #ifdef CONFIG_ACPI
> @@ -220,6 +221,7 @@ struct global_params {
> * preference/bias
> * @epp_saved: Saved EPP/EPB during system suspend or
> CPU offline
> * operation
> + * @epp_cached Cached HWP energy-performance
> preference value
> * @hwp_req_cached: Cached value of the last HWP Request MSR
> * @hwp_cap_cached: Cached value of the last HWP Capabilities MSR
> * @last_io_update: Last time when IO wake flag was set
> @@ -257,6 +259,7 @@ struct cpudata {
> s16 epp_policy;
> s16 epp_default;
> s16 epp_saved;
> + s16 epp_cached;
> u64 hwp_req_cached;
> u64 hwp_cap_cached;
> u64 last_io_update;
> @@ -690,6 +693,8 @@ static ssize_t show_energy_performance_a
>
> cpufreq_freq_attr_ro(energy_performance_available_preferences);
>
> +static struct cpufreq_driver intel_pstate;
> +
> static ssize_t store_energy_performance_preference(
> struct cpufreq_policy *policy, const char *buf, size_t
> count)
> {
> @@ -718,14 +723,35 @@ static ssize_t store_energy_performance_
> raw = true;
> }
>
> + mutex_lock(&intel_pstate_driver_lock);
> +
> + if (!intel_pstate_driver) {
> + mutex_unlock(&intel_pstate_driver_lock);
> + return -EAGAIN;
> + }
> +
> mutex_lock(&intel_pstate_limits_lock);
>
> - ret = intel_pstate_set_energy_pref_index(cpu_data, ret, raw,
> epp);
> - if (!ret)
> + if (intel_pstate_driver == &intel_psta
Re: WARNING in hci_conn_timeout
syzbot has bisected this issue to:
commit 3d30311c0e4d834c94e6a27d6242a942d6a76b85
Author: Varsha Rao
Date: Sun Oct 9 11:13:56 2016 +
staging: vt6655: Removes unnecessary blank lines.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17023a1490
start commit: 7dc6fd0f Merge branch 'i2c/for-current' of git://git.kerne..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=14823a1490
console output: https://syzkaller.appspot.com/x/log.txt?x=10823a1490
kernel config: https://syzkaller.appspot.com/x/.config?x=e59ee776d5aa8d55
dashboard link: https://syzkaller.appspot.com/bug?extid=2446dd3cb07277388db6
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13f781d490
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=116a0c1490
Reported-by: syzbot+2446dd3cb07277388...@syzkaller.appspotmail.com
Fixes: 3d30311c0e4d ("staging: vt6655: Removes unnecessary blank lines.")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH v2 1/2] MAINTAINERS: Remove JZ4780 DMA driver entry
On Sun, 26 Jul 2020, Krzysztof Kozlowski wrote: > diff --git a/MAINTAINERS b/MAINTAINERS > index cba0ed5b..362863cae239 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8541,11 +8541,6 @@ F: include/uapi/rdma/ > F: samples/bpf/ibumad_kern.c > F: samples/bpf/ibumad_user.c > > -INGENIC JZ4780 DMA Driver > -M: Zubair Lutfullah Kakakhel > -S: Maintained > -F: drivers/dma/dma-jz4780.c > - FYI, the usual approach would be marking the entry "Orphan" rather than removing it entirely, so that the mapping remains and makes it easy for someone to pick it up. Maciej
drivers/input/touchscreen/elants_i2c.c:859:45: warning: Clarify calculation precedence for '&' and
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d52daa8620c65960e1ef882adc1f92061326bd7a
commit: f27ad8932725f8dd0cd1a46763de4a40377b1ae6 Input: elants_i2c - support
palm detection
date: 4 months ago
compiler: xtensa-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
cppcheck warnings: (new ones prefixed by >>)
>> drivers/input/touchscreen/elants_i2c.c:859:45: warning: Clarify calculation
>> precedence for '&' and '?'. [clarifyCalculation]
tool_type = buf[FW_POS_TOOL_TYPE] & BIT(0) ?
^
vim +859 drivers/input/touchscreen/elants_i2c.c
838
839 /*
840 * Event reporting.
841 */
842
843 static void elants_i2c_mt_event(struct elants_data *ts, u8 *buf)
844 {
845 struct input_dev *input = ts->input;
846 unsigned int n_fingers;
847 unsigned int tool_type;
848 u16 finger_state;
849 int i;
850
851 n_fingers = buf[FW_POS_STATE + 1] & 0x0f;
852 finger_state = ((buf[FW_POS_STATE + 1] & 0x30) << 4) |
853 buf[FW_POS_STATE];
854
855 dev_dbg(&ts->client->dev,
856 "n_fingers: %u, state: %04x\n", n_fingers,
finger_state);
857
858 /* Note: all fingers have the same tool type */
> 859 tool_type = buf[FW_POS_TOOL_TYPE] & BIT(0) ?
860 MT_TOOL_FINGER : MT_TOOL_PALM;
861
862 for (i = 0; i < MAX_CONTACT_NUM && n_fingers; i++) {
863 if (finger_state & 1) {
864 unsigned int x, y, p, w;
865 u8 *pos;
866
867 pos = &buf[FW_POS_XY + i * 3];
868 x = (((u16)pos[0] & 0xf0) << 4) | pos[1];
869 y = (((u16)pos[0] & 0x0f) << 8) | pos[2];
870 p = buf[FW_POS_PRESSURE + i];
871 w = buf[FW_POS_WIDTH + i];
872
873 dev_dbg(&ts->client->dev, "i=%d x=%d y=%d p=%d
w=%d\n",
874 i, x, y, p, w);
875
876 input_mt_slot(input, i);
877 input_mt_report_slot_state(input, tool_type,
true);
878 input_event(input, EV_ABS, ABS_MT_POSITION_X,
x);
879 input_event(input, EV_ABS, ABS_MT_POSITION_Y,
y);
880 input_event(input, EV_ABS, ABS_MT_PRESSURE, p);
881 input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR,
w);
882
883 n_fingers--;
884 }
885
886 finger_state >>= 1;
887 }
888
889 input_mt_sync_frame(input);
890 input_sync(input);
891 }
892
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v6] staging: atomisp: move null check to earlier point
`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.
In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
/* v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.
Signed-off-by: Cengiz Can
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab
---
Please do note that this change introduces a new return value to
`gmin_v2p8_ctrl()`.
[NEW] - raise a WARN and return -ENODEV if there are no subdevices.
- return result of `gpio_request` or `gpio_direction_output`.
- return 0 if GPIO is ON.
- return results of `regulator_enable` or `regulator_disable`.
- according to PMIC type, return result of `axp_regulator_set`
or `gmin_i2c_write`.
- return -EINVAL if unknown PMIC type.
Patch Changelog:
v4: Fix minor typo in commit message
v5: Remove typo from email subject
v6: Remove duplicate Signed-off-by tag
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
int ret;
int value;
+ if (WARN_ON(!gs))
+ return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
pr_err("V2P8 GPIO initialization failed\n");
}
- if (!gs || gs->v2p8_on == on)
+ if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
--
2.27.0
[PATCH v5] staging: atomisp: move null check to earlier point
`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.
In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
/* v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.
Signed-off-by: Cengiz Can
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab
Signed-off-by: Cengiz Can
---
Please do note that this change introduces a new return value to
`gmin_v2p8_ctrl()`.
[NEW] - raise a WARN and return -ENODEV if there are no subdevices.
- return result of `gpio_request` or `gpio_direction_output`.
- return 0 if GPIO is ON.
- return results of `regulator_enable` or `regulator_disable`.
- according to PMIC type, return result of `axp_regulator_set`
or `gmin_i2c_write`.
- return -EINVAL if unknown PMIC type.
Patch Changelog:
v4: Fix minor typo in commit message
v5: Remove typo from email subject
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
int ret;
int value;
+ if (WARN_ON(!gs))
+ return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
pr_err("V2P8 GPIO initialization failed\n");
}
- if (!gs || gs->v2p8_on == on)
+ if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
--
2.27.0
[PATCHi v4] staging: atomisp: move null check to earlier point
`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.
In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
/* v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.
Signed-off-by: Cengiz Can
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab
Signed-off-by: Cengiz Can
---
Please do note that this change introduces a new return value to
`gmin_v2p8_ctrl`.
[NEW] - raise a WARN and return -ENODEV if there are no subdevices.
- return result of `gpio_request` or `gpio_direction_output`.
- return 0 if GPIO is ON.
- return results of `regulator_enable` or `regulator_disable`.
- according to PMIC type, return result of `axp_regulator_set`
or `gmin_i2c_write`.
- return -EINVAL if unknown PMIC type.
Patch Changelog:
v4: Fix minor typo in commit message
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
int ret;
int value;
+ if (WARN_ON(!gs))
+ return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
pr_err("V2P8 GPIO initialization failed\n");
}
- if (!gs || gs->v2p8_on == on)
+ if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
--
2.27.0
[PATCH v3] staging: atomisp: move null check to earlier point
`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.
In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:
/* Acquired here v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
/* v--Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
With this change we're null checking `find_gmin_subdev()` result
and return we return an error if that's the case. We also WARN()
for the sake of debugging.
Signed-off-by: Cengiz Can
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab
---
Please do note that this change introduces a new return value to
`gmin_v2p8_ctrl`.
[NEW] - raise a WARN and return -ENODEV if there are no subdevices.
- return result of `gpio_request` or `gpio_direction_output`.
- return 0 if GPIO is ON.
- return results of `regulator_enable` or `regulator_disable`.
- according to PMIC type, return result of `axp_regulator_set`
or `gmin_i2c_write`.
- return -EINVAL if unknown PMIC type.
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 0df46a1af5f0..1ad0246764a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -871,6 +871,9 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
int ret;
int value;
+ if (WARN_ON(!gs))
+ return -ENODEV;
+
if (gs->v2p8_gpio >= 0) {
pr_info("atomisp_gmin_platform: 2.8v power on GPIO %d\n",
gs->v2p8_gpio);
@@ -881,7 +884,7 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
pr_err("V2P8 GPIO initialization failed\n");
}
- if (!gs || gs->v2p8_on == on)
+ if (gs->v2p8_on == on)
return 0;
gs->v2p8_on = on;
--
2.27.0
[GIT] Networking
1) Encap offset calculation is incorrect in esp6, from Sabrina Dubroca. 2) Better parameter validation in pfkey_dump(), from Mark Salyzyn. 3) Fix several clang issues on powerpc in selftests, from Tanner Love. 4) cmsghdr_from_user_compat_to_kern() uses the wrong length, from Al Viro. 5) Out of bounds access in mlx5e driver, from Raed Salem. 6) Fix transfer buffer memleak in lan78xx, from Johan Havold. 7) RCU fixups in rhashtable, from Herbert Xu. 8) Fix ipv6 nexthop refcnt leak, from Xiyu Yang. 9) vxlan FDB dump must be done under RCU, from Ido Schimmel. 10) Fix use after free in mlxsw, from Ido Schimmel. 11) Fix map leak in HASH_OF_MAPS bpf code, from Andrii Nakryiko. 12) Fix bug in mac80211 Tx ack status reporting, from Vasanthakumar Thiagarajan. 13) Fix memory leaks in IPV6_ADDRFORM code, from Cong Wang. 14) Fix bpf program reference count leaks in mlx5 during mlx5e_alloc_rq(), from Xin Xiong. Please pull, thanks a lot! The following changes since commit 04300d66f0a06d572d9f2ad6768c38cabde22179: Merge tag 'riscv-for-linus-5.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux into master (2020-07-25 14:42:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git for you to fetch changes up to fda2ec62cf1aa7cbee52289dc8059cd3662795da: vxlan: fix memleak of fdb (2020-08-01 11:49:18 -0700) Aaron Ma (1): e1000e: continue to init PHY even when failed to disable ULP Al Viro (1): fix a braino in cmsghdr_from_user_compat_to_kern() Alaa Hleihel (1): net/mlx5e: Fix kernel crash when setting vf VLANID on a VF dev Amit Cohen (1): selftests: ethtool: Fix test when only two speeds are supported Andrii Nakryiko (2): bpf: Fix map leak in HASH_OF_MAPS map selftests/bpf: Extend map-in-map selftest to detect memory leaks Aya Levin (1): net/mlx5e: Fix error path of device attach Christoph Hellwig (1): net/bpfilter: Initialize pos in __bpfilter_process_sockopt Cong Wang (1): ipv6: fix memory leaks on IPV6_ADDRFORM path David Howells (1): rxrpc: Fix race between recvmsg and sendmsg on immediate call failure David S. Miller (12): Merge branch 'selftests-net-Fix-clang-warnings-on-powerpc' Merge branch 'hns3-fixes' Merge branch 'net-lan78xx-fix-NULL-deref-and-memory-leak' Merge tag 'mlx5-fixes-2020-07-28' of git://git.kernel.org/.../saeed/linux Merge branch 'rhashtable-Fix-unprotected-RCU-dereference-in-__rht_ptr' Merge branch 'Fix-bugs-in-Octeontx2-netdev-driver' Merge branch 'mlxsw-fixes' Merge tag 'mac80211-for-davem-2020-07-30' of git://git.kernel.org/.../jberg/mac80211 Merge branch '1GbE' of git://git.kernel.org/.../jkirsher/net-queue Merge tag 'mlx5-fixes-2020-07-30' of git://git.kernel.org/.../saeed/linux Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec Merge git://git.kernel.org/.../bpf/bpf Eran Ben Elisha (3): net/mlx5: Fix a bug of using ptp channel index as pin index net/mlx5: Verify Hardware supports requested ptp function on a given pin net/mlx5: Query PPS pin operational status before registering it Felix Fietkau (1): mac80211: remove STA txq pending airtime underflow warning Francesco Ruggeri (1): igb: reinit_locked() should be called with rtnl_lock Guillaume Nault (1): bareudp: forbid mixing IP and MPLS in multiproto mode Guojia Liao (2): net: hns3: fix aRFS FD rules leftover after add a user FD rule net: hns3: fix for VLAN config when reset failed Hangbin Liu (1): selftests/bpf: fix netdevsim trap_flow_action_cookie read Herbert Xu (2): rhashtable: Fix unprotected RCU dereference in __rht_ptr rhashtable: Restore RCU marking on rhash_lock_head Ido Schimmel (7): vxlan: Ensure FDB dump is performed under RCU ipv4: Silence suspicious RCU usage warning mlxsw: spectrum_router: Allow programming link-local host routes mlxsw: spectrum: Use different trap group for externally routed packets mlxsw: core: Increase scope of RCU read-side critical section mlxsw: core: Free EMAD transactions using kfree_rcu() mlxsw: spectrum_router: Fix use-after-free in router init / de-init Jakub Kicinski (2): mlx4: disable device on shutdown devlink: ignore -EOPNOTSUPP errors on dumpit Jean-Philippe Brucker (1): selftests/bpf: Fix cgroup sockopt verifier test Jian Shen (1): net: hns3: add reset check for VF updating port based VLAN Jianbo Liu (3): net/mlx5e: CT: Support restore ipv6 tunnel net/mlx5e: E-Switch, Add misc bit when misc fields changed for mirroring net/mlx5e: E-Switch, Specify flow_source for rule with no in_port Johan Hovold (3): net: lan78xx: add missing endpoint sanity check net: lan78xx: fix transfer-buffer memory leak
Re: [PATCH net-next RFC 01/13] devlink: Add reload level option to devlink reload command
On 7/31/2020 2:11 AM, Jakub Kicinski wrote:
On Thu, 30 Jul 2020 15:30:45 +0300 Moshe Shemesh wrote:
My expectations would be that the driver must perform the lowest
reset level possible that satisfies the requested functional change.
IOW driver may do more, in fact it should be acceptable for the
driver to always for a full HW reset (unless --live or other
constraint is specified).
OK, but some combinations may still not be valid for specific driver
even if it tries lowest level possible.
Can you give an example?
For example take the combination of fw-live-patch and param-init.
The fw-live-patch needs no re-initialization, while the param-init
requires driver re-initialization.
So the only way to do that is to the one command after the other, not
really combining.
You need to read my responses more carefully. I don't have
fw-live-patch in my proposal. The operation is fw-activate,
--live is independent and an constraint, not an operation.
OK, I probably didn't get the whole picture right.
I am not sure I got it yet, please review if that's the uAPI that you
mean to:
devlink dev reload [ net-ns-respawn { PID | NAME | ID } ] [
driver-param-init ] [ fw-activate [ --live] ]
Also, I recall that before devlink param was added the devlink reload
was used for devlink resources.
I am not sure it is still used for devlink resources as I don't see it
in the code of devlink reload.
But if it is we probably should add it as another operation.
Jiri, please comment on that.
Re: [PATCH v3 2/6] dt-bindings: net: can: binding for CTU CAN FD open-source IP core.
Hello Rob ad others, On Wednesday 29 of July 2020 01:12:31 Pavel Pisa wrote: > On Saturday 04 of January 2020 00:53:59 Rob Herring wrote: > > On Sat, Dec 21, 2019 at 03:07:31PM +0100, p...@cmp.felk.cvut.cz wrote: > > > From: Pavel Pisa > > > > > > Signed-off-by: Pavel Pisa > > > --- > > > .../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61 > > > ++ 1 file changed, 61 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt > > > > Bindings are moving DT schema format now. Not something I'd require on a > > respin I've already reviewed, but OTOH it's been 10 months to respin > > from v2. So: > > > > Reviewed-by: Rob Herring > > > > If you have a v4, then please convert to a schema. > ... > I am trying to resolve that only one review feedback which I have received > before v4 patches sending. I have spent half day to update and integrate > self build packages to my stable Debian to can run > >make -k dt_binding_check > > but unfortunately, I have not achieved promissing result even when tested > on Linux kernel unpatched sources. I used actual git > dt-schema/dt-doc-validate with 5.4 kernel build but I get only long series > of I have succeed to run make dt_binding_check on stable Debian with 5.4 kernel with only denumerable bunch of errors, probably normal one. Details to make dt_binding_check usable on stable Debian later. When invoked with base directory specified /usr/local/bin/dt-doc-validate -u /usr/src/linux-5.4/Documentation/devicetree/bindings/ net/can/ctu,ctucanfd.yaml then no problem is reported in ctu,ctucanfd.yaml . Please is the specification correct even after human check? > pi@baree:/usr/src/linux-5.4-rt/_build/arm/px6$ make dt_binding_check -k > GNUmakefile:40: *** mixed implicit and normal rules: deprecated syntax > make -C /usr/src/linux-5.4-rt O=/usr/src/linux-5.4-rt/_build/arm/px6/ > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- QTDIR=/usr/share/qt4 > dt_binding_check CHKDT Documentation/devicetree/bindings/arm/actions.yaml > /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/actions.yaml: > found incompatible YAML document in "", line 2, column 1 > make[3]: *** The remark to save time of others, actual stable Debian Buster provides package python3-ruamel.yaml in 0.15.34-1+b1 version. But use of make dt_binding_check and dt-doc-validate and dt-validate with this version lead to many errors "found incompatible YAML document". The validation tools can be make to work when next packages are added and replaced in stable Debian python3-pyrsistent 0.15.5-1 python3-pyfakefs 4.0.2-1 python3-zipp 1.0.0-3 python3-importlib-metadata 1.6.0 python3-jsonschema 3.2.0-3 python3-ruamel.yaml.clib 0.2.0-3 python3-ruamel.yaml 0.16.10-2 The dependencies and interdependence of the tools are really wide and that the tools are unusable in the actual regular Debian stable distribution should be described somewhere visible enough to save developers time. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://dce.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/
[GIT PULL] thread fix v5.8-rc8
Hey Linus, /* Summary */ This contains a simple spelling fix for dequeue_synchronous_signal(). /* Testing */ All patches have seen exposure in linux-next and are based on v5.8-rc7. /* Conflicts */ At the time of creating this pr no merge conflicts were reported. The following changes since commit 92ed301919932f13b9172e525674157e983d: Linux 5.8-rc7 (2020-07-26 14:14:06 -0700) are available in the Git repository at: g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux tags/for-linus-2020-08-01 for you to fetch changes up to 7665a47f70b3f64bf09c233cc7df73fde9e506f1: signal: fix typo in dequeue_synchronous_signal() (2020-07-26 23:57:52 +0200) Please consider pulling these changes from the signed for-linus-2020-08-01 tag. Thanks! Christian for-linus-2020-08-01 Pavel Machek (1): signal: fix typo in dequeue_synchronous_signal() kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] staging: rts5208: clear alignment style issues
Clear checkpatch alignment style issues in rtsx_transport.c.
CHECK: Alignment should match open parenthesis
Signed-off-by: Tomer Samara
---
drivers/staging/rts5208/rtsx_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rts5208/rtsx_transport.c
b/drivers/staging/rts5208/rtsx_transport.c
index 5f1eefe80f1e..0027bcf638ad 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -678,7 +678,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8
card, void *buf,
/* Wait for TRANS_OK_INT */
timeleft = wait_for_completion_interruptible_timeout(&trans_done,
- msecs_to_jiffies(timeout));
+
msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
--
2.25.1
general protection fault in free_swap_cache
Hello, syzbot found the following issue on: HEAD commit:92ed3019 Linux 5.8-rc7 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1570213890 kernel config: https://syzkaller.appspot.com/x/.config?x=84f076779e989e69 dashboard link: https://syzkaller.appspot.com/bug?extid=10e0e0681594086f6872 compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+10e0e0681594086f6...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc43a5d1: [#1] PREEMPT SMP KASAN KASAN: probably user-memory-access in range [0x021d2e88-0x021d2e8f] CPU: 1 PID: 31709 Comm: syz-executor.1 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:compound_head include/linux/page-flags.h:182 [inline] RIP: 0010:PageSwapCache include/linux/page-flags.h:391 [inline] RIP: 0010:free_swap_cache+0x28/0x300 mm/swap_state.c:266 Code: c3 90 41 57 41 56 41 55 41 54 49 89 fc 55 4d 8d 6c 24 08 53 e8 49 b3 c7 ff 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 85 02 00 00 4d 8b 74 24 08 31 ff 4c 89 e5 4c 89 RSP: 0018:c9001831f900 EFLAGS: 00010206 RAX: dc00 RBX: 888000163028 RCX: 81ac3992 RDX: 0043a5d1 RSI: 81ac0987 RDI: 021d2e80 RBP: 0003 R08: R09: ea00021d2e47 R10: 01fe R11: R12: 021d2e80 R13: 021d2e88 R14: dc00 R15: c9001831fcb0 FS: () GS:8880ae70() knlGS: CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 08157854 CR3: 92a01000 CR4: 001426e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: free_pages_and_swap_cache+0x58/0x90 mm/swap_state.c:294 tlb_batch_pages_flush mm/mmu_gather.c:49 [inline] tlb_flush_mmu_free mm/mmu_gather.c:242 [inline] tlb_flush_mmu+0xe9/0x6b0 mm/mmu_gather.c:249 zap_pte_range mm/memory.c:1155 [inline] zap_pmd_range mm/memory.c:1193 [inline] zap_pud_range mm/memory.c:1222 [inline] zap_p4d_range mm/memory.c:1243 [inline] unmap_page_range+0x1bd4/0x2940 mm/memory.c:1264 unmap_single_vma+0x198/0x300 mm/memory.c:1309 unmap_vmas+0x16f/0x2f0 mm/memory.c:1341 exit_mmap+0x2b1/0x510 mm/mmap.c:3162 __mmput+0x122/0x470 kernel/fork.c:1093 mmput+0x53/0x60 kernel/fork.c:1114 exit_mm kernel/exit.c:482 [inline] do_exit+0xa8f/0x2a40 kernel/exit.c:792 do_group_exit+0x125/0x310 kernel/exit.c:903 __do_sys_exit_group kernel/exit.c:914 [inline] __se_sys_exit_group kernel/exit.c:912 [inline] __ia32_sys_exit_group+0x3a/0x50 kernel/exit.c:912 do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428 __do_fast_syscall_32 arch/x86/entry/common.c:475 [inline] do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7fec569 Code: Bad RIP value. RSP: 002b:086afd7c EFLAGS: 0202 ORIG_RAX: 00fc RAX: ffda RBX: RCX: 0001 RDX: RSI: RDI: 0805a92b RBP: fff7 R08: R09: R10: R11: R12: R13: R14: R15: Modules linked in: ---[ end trace 58b8e3320e616211 ]--- RIP: 0010:compound_head include/linux/page-flags.h:182 [inline] RIP: 0010:PageSwapCache include/linux/page-flags.h:391 [inline] RIP: 0010:free_swap_cache+0x28/0x300 mm/swap_state.c:266 Code: c3 90 41 57 41 56 41 55 41 54 49 89 fc 55 4d 8d 6c 24 08 53 e8 49 b3 c7 ff 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 85 02 00 00 4d 8b 74 24 08 31 ff 4c 89 e5 4c 89 RSP: 0018:c9001831f900 EFLAGS: 00010206 RAX: dc00 RBX: 888000163028 RCX: 81ac3992 RDX: 0043a5d1 RSI: 81ac0987 RDI: 021d2e80 RBP: 0003 R08: R09: ea00021d2e47 R10: 01fe R11: R12: 021d2e80 R13: 021d2e88 R14: dc00 R15: c9001831fcb0 FS: () GS:8880ae60() knlGS: CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: 2ef2a000 CR3: 932f4000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report 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 issue. See:
include/linux/spinlock.h:408:9: sparse: sparse: context imbalance in 'qlt_24xx_atio_pkt_all_vps' - unexpected unlock
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d52daa8620c65960e1ef882adc1f92061326bd7a commit: 21038b0900d1b8728ec77d9286d7b0b57ca7b585 scsi: qla2xxx: Fix endianness annotations in header files date: 2 months ago config: x86_64-randconfig-s022-20200802 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-115-g5fc204f2-dirty git checkout 21038b0900d1b8728ec77d9286d7b0b57ca7b585 # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/scsi/qla2xxx/qla_target.c:1699:52: sparse: sparse: restricted __le16 degrades to integer drivers/scsi/qla2xxx/qla_target.c:1700:25: sparse: sparse: restricted __le32 degrades to integer drivers/scsi/qla2xxx/qla_target.c:1699:37: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le16 [usertype] flags @@ got unsigned int @@ drivers/scsi/qla2xxx/qla_target.c:1699:37: sparse: expected restricted __le16 [usertype] flags drivers/scsi/qla2xxx/qla_target.c:1699:37: sparse: got unsigned int drivers/scsi/qla2xxx/qla_target.c:2136:28: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned int [usertype] tag @@ got restricted __le32 [usertype] exchange_addr_to_abort @@ drivers/scsi/qla2xxx/qla_target.c:2136:28: sparse: expected unsigned int [usertype] tag drivers/scsi/qla2xxx/qla_target.c:2136:28: sparse: got restricted __le32 [usertype] exchange_addr_to_abort drivers/scsi/qla2xxx/qla_target.c:381:36: sparse: sparse: restricted __le16 degrades to integer drivers/scsi/qla2xxx/qla_target.c:1769:15: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] f_ctl @@ got restricted __le32 [usertype] @@ drivers/scsi/qla2xxx/qla_target.c:1769:15: sparse: expected unsigned int [usertype] f_ctl drivers/scsi/qla2xxx/qla_target.c:1769:15: sparse: got restricted __le32 [usertype] drivers/scsi/qla2xxx/qla_target.c:1785:52: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le16 [usertype] high_seq_cnt @@ got int @@ drivers/scsi/qla2xxx/qla_target.c:1785:52: sparse: expected restricted __le16 [usertype] high_seq_cnt drivers/scsi/qla2xxx/qla_target.c:1785:52: sparse: got int drivers/scsi/qla2xxx/qla_target.c:1841:15: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] f_ctl @@ got restricted __le32 [usertype] @@ drivers/scsi/qla2xxx/qla_target.c:1841:15: sparse: expected unsigned int [usertype] f_ctl drivers/scsi/qla2xxx/qla_target.c:1841:15: sparse: got restricted __le32 [usertype] drivers/scsi/qla2xxx/qla_target.c:1860:52: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le16 [usertype] high_seq_cnt @@ got int @@ drivers/scsi/qla2xxx/qla_target.c:1860:52: sparse: expected restricted __le16 [usertype] high_seq_cnt drivers/scsi/qla2xxx/qla_target.c:1860:52: sparse: got int drivers/scsi/qla2xxx/qla_target.c:2033:21: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] tag @@ got restricted __le32 [usertype] exchange_addr_to_abort @@ drivers/scsi/qla2xxx/qla_target.c:2033:21: sparse: expected unsigned int [usertype] tag drivers/scsi/qla2xxx/qla_target.c:2033:21: sparse: got restricted __le32 [usertype] exchange_addr_to_abort drivers/scsi/qla2xxx/qla_target.c:2113:25: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned long long [usertype] @@ got restricted __le32 [usertype] exchange_addr_to_abort @@ drivers/scsi/qla2xxx/qla_target.c:2113:25: sparse: expected unsigned long long [usertype] drivers/scsi/qla2xxx/qla_target.c:2113:25: sparse: got restricted __le32 [usertype] exchange_addr_to_abort drivers/scsi/qla2xxx/qla_target.c:2226:28: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le16 [usertype] nport_handle @@ got unsigned short [usertype] loop_id @@ drivers/scsi/qla2xxx/qla_target.c:2226:28: sparse: expected restricted __le16 [usertype] nport_handle drivers/scsi/qla2xxx/qla_target.c:2226:28: sparse: got unsigned short [usertype] loop_id drivers/scsi/qla2xxx/qla_target.c:2283:28: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le16 [usertype] nport_handle @@ got unsigned short [usertype] loop_id @@ drivers/scsi/qla2xxx/qla_target.
Re: [PATCH net-next v3 2/2] net: dsa: qca8k: Add 802.1q VLAN support
On 8/1/2020 10:06 AM, Jonathan McDowell wrote: > This adds full 802.1q VLAN support to the qca8k, allowing the use of > vlan_filtering and more complicated bridging setups than allowed by > basic port VLAN support. > > Tested with a number of untagged ports with separate VLANs and then a > trunk port with all the VLANs tagged on it. > > v3: > - Pull QCA8K_PORT_VID_DEF changes into separate cleanup patch > - Reverse Christmas tree notation for variable definitions > - Use untagged instead of tagged for consistency > v2: > - Return sensible errnos on failure rather than -1 (rmk) > - Style cleanups based on Florian's feedback > - Silently allow VLAN 0 as device correctly treats this as no tag > > Signed-off-by: Jonathan McDowell Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH net-next v3 1/2] net: dsa: qca8k: Add define for port VID
On 8/1/2020 10:05 AM, Jonathan McDowell wrote: > Rather than using a magic value of 1 when configuring the port VIDs add > a QCA8K_PORT_VID_DEF define and use that instead. Also fix up the > bitmask in the process; the top 4 bits are reserved so this wasn't a > problem, but only masking 12 bits is the correct approach. > > Signed-off-by: Jonathan McDowell Reviewed-by: Florian Fainelli -- Florian
WAITING FOR YOUR URGENT RESPONSE!!!
Dear Friend, I am Mr.Ali Zango Working with a reputable bank here in Burkina Faso as the manager in audit department. During our last banking audits we discovered an abandoned account belongs to one of our deceased customer, late Mr.Hamid Amine Razzaq, a billionaire businessman. Meanwhile, before i contacted you i have done personal investigation in locating any of his relatives who knows about the account, but i came out unsuccessful. I am writing to request your assistance in transferring the sum of 10.500.000.00 (Ten million Five Hundred Thousand Dollars) into your account. I decided to contact you to act as his foreign business partner so that my bank will accord you the recognition and have the fund transfer into your account. However, i will give you full details on how the business will be executed and also note that you will have 40% of the above mentioned if you agree to handle this business with me while 50% will be for me and 10% for any expenses that may arise on the process. I am expecting to read from you soon. Best Regards Mr. Ali Zango. mr.ali.za...@gmail.com
ERROR: "min_low_pfn" undefined!
Hi Jiri, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d52daa8620c65960e1ef882adc1f92061326bd7a commit: aebe5fc3b5685e1d9b86cc8314a8e8f3c6f3284e n_hdlc: put init/exit strings directly to prints date: 5 months ago config: microblaze-randconfig-r026-20200801 (attached as .config) compiler: microblaze-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout aebe5fc3b5685e1d9b86cc8314a8e8f3c6f3284e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=microblaze If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined! >> ERROR: "min_low_pfn" [drivers/mtd/nand/raw/cadence-nand-controller.ko] >> undefined! >> ERROR: "min_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v7 2/2] tmpfs: Support 64-bit inums per-sb
On Mon, 13 Jul 2020, Chris Down wrote:
> The default is still set to inode32 for backwards compatibility, but
> system administrators can opt in to the new 64-bit inode numbers by
> either:
>
> 1. Passing inode64 on the command line when mounting, or
> 2. Configuring the kernel with CONFIG_TMPFS_INODE64=y
>
> The inode64 and inode32 names are used based on existing precedent from
> XFS.
>
> Signed-off-by: Chris Down
> Reviewed-by: Amir Goldstein
> Cc: Hugh Dickins
Acked-by: Hugh Dickins
Again, thanks, and comments below, but nothing to override tha Ack.
> Cc: Andrew Morton
> Cc: Al Viro
> Cc: Matthew Wilcox
> Cc: Jeff Layton
> Cc: Johannes Weiner
> Cc: Tejun Heo
> Cc: linux...@kvack.org
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: kernel-t...@fb.com
> ---
> Documentation/filesystems/tmpfs.rst | 11 +
> fs/Kconfig | 15 +++
> include/linux/shmem_fs.h| 1 +
> mm/shmem.c | 65 -
> 4 files changed, 90 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/filesystems/tmpfs.rst
> b/Documentation/filesystems/tmpfs.rst
> index 4e95929301a5..47b84ddaa8bb 100644
> --- a/Documentation/filesystems/tmpfs.rst
> +++ b/Documentation/filesystems/tmpfs.rst
> @@ -150,6 +150,15 @@ These options do not have any effect on remount. You can
> change these
> parameters with chmod(1), chown(1) and chgrp(1) on a mounted filesystem.
>
>
> +tmpfs has a mount option to select whether it will wrap at 32- or 64-bit
> inode
> +numbers:
> +
> +inode64 Use 64-bit inode numbers
> +inode32 Use 32-bit inode numbers
> +
> +On 64-bit, the default is set by CONFIG_TMPFS_INODE64. On 32-bit, inode64 is
> +not legal and will produce an error at mount time.
> +
I did originally want to move this up higher, between the discussion
of nr_inodes and mpol; but its placing here follows where you placed
it in /proc/mounts, and I end up agreeing with that, so let's leave
where you've placed it.
But this is a description of a new pair of mount options, nothing to
do with the paragraph below, so one more blank line is needed.
Except that tmpfs.txt has now been replaced by tmpfs.rst, with some
ing too. We'd better add that. I'm unfamiliar with, and not
prepared for .rst - getting Doc right has become a job for specialists.
I'll send a -fix.patch of how how I think it should look to Andrew and
Randy Dunlap, hoping Randy can confirm whether it ends up right.
> So 'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs'
> will give you tmpfs instance on /mytmpfs which can allocate 10GB
> RAM/SWAP in 10240 inodes and it is only accessible by root.
> @@ -161,3 +170,5 @@ RAM/SWAP in 10240 inodes and it is only accessible by
> root.
> Hugh Dickins, 4 June 2007
> :Updated:
> KOSAKI Motohiro, 16 Mar 2010
> +Updated:
I bet that should say ":Updated:" now.
> + Chris Down, 13 July 2020
> diff --git a/fs/Kconfig b/fs/Kconfig
> index ff257b81fde5..64d530ba42f6 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -229,6 +229,21 @@ config TMPFS_XATTR
>
> If unsure, say N.
>
> +config TMPFS_INODE64
> + bool "Use 64-bit ino_t by default in tmpfs"
> + depends on TMPFS && 64BIT
> + default n
Okay: I haven't looked up what our last position was on which way the
default should be, but I do recall that we were reluctantly realizing
that we couldn't safely be as radical as we had hoped.
As to "default n" being the default and unnecessary: I don't mind
seeing it there explicitly, let's give the work to whoever wants to
delete that line.
> + help
> + tmpfs has historically used only inode numbers as wide as an unsigned
> + int. In some cases this can cause wraparound, potentially resulting in
> + multiple files with the same inode number on a single device. This
> option
> + makes tmpfs use the full width of ino_t by default, similarly to the
> + inode64 mount option.
I've just realized that this, and the inode64 Documentation, make no
mention of why you might not want to enable it: it sounds like such a
good thing, with the documentation on why not in include/linux/fs.h.
I'd better add some text to these in the -fix.patch.
> +
> + To override this default, use the inode32 or inode64 mount options.
> +
> + If unsure, say N.
> +
> config HUGETLBFS
> bool "HugeTLB file system support"
> depends on X86 || IA64 || SPARC64 || (S390 && 64BIT) || \
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index eb628696ec66..a5a5d1d4d7b1 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -36,6 +36,7 @@ struct shmem_sb_info {
> unsigned char huge; /* Whether to try for hugepages */
> kuid_t uid; /* Mount uid for root directory */
> kgid_t gid; /* Mount gid for root directory */
> + bool full_inums;
Re: [PATCH 2/4] audit: uninitialize global variable audit_sig_sid
On Sat, Aug 1, 2020 at 2:55 PM Joe Perches wrote: > On Sat, 2020-08-01 at 19:46 +0100, Jules Irenge wrote: > > Checkpatch tool reports an error at variable audit_sig_sid declaration > [] > > diff --git a/kernel/audit.c b/kernel/audit.c > [] > > @@ -125,7 +125,7 @@ static u32audit_backlog_wait_time = > > AUDIT_BACKLOG_WAIT_TIME; > > /* The identity of the user shutting down the audit system. */ > > kuid_t audit_sig_uid = INVALID_UID; > > pid_taudit_sig_pid = -1; > > -u32 audit_sig_sid = 0; > > +u32 audit_sig_sid; > > All of these are unused outside of audit.c and might as > well be static and removed from the .h file. There's plenty of time before the merge window closes, doing this would definitely make this patch much more useful than the typical checkpatch noise. -- paul moore www.paul-moore.com
[tip:sched/core] BUILD SUCCESS 949bcb8135a96a6923e676646bd29cbe69e8350f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core branch HEAD: 949bcb8135a96a6923e676646bd29cbe69e8350f sched/doc: Factorize bits between sched-energy.rst & sched-capacity.rst elapsed time: 724m configs tested: 76 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm cm_x300_defconfig sh kfr2r09_defconfig armpleb_defconfig mips mips_paravirt_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20200802 x86_64 randconfig-a001-20200802 x86_64 randconfig-a004-20200802 x86_64 randconfig-a003-20200802 x86_64 randconfig-a002-20200802 x86_64 randconfig-a005-20200802 i386 randconfig-a005-20200731 i386 randconfig-a004-20200731 i386 randconfig-a006-20200731 i386 randconfig-a002-20200731 i386 randconfig-a001-20200731 i386 randconfig-a003-20200731 x86_64 randconfig-a015-20200731 x86_64 randconfig-a014-20200731 x86_64 randconfig-a016-20200731 x86_64 randconfig-a012-20200731 x86_64 randconfig-a013-20200731 x86_64 randconfig-a011-20200731 i386 randconfig-a016-20200731 i386 randconfig-a012-20200731 i386 randconfig-a014-20200731 i386 randconfig-a015-20200731 i386 randconfig-a011-20200731 i386 randconfig-a013-20200731 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH 3/4] audit: uninitialize static variables
On Sat, Aug 1, 2020 at 2:46 PM Jules Irenge wrote:
>
> Checkpatch tool reports an error at variable declaration
>
> "ERROR: do not initialise statics to 0"
>
> This is due to the fact that these variables are stored in the buffer
> In the .bss section, one can not set an initial value
> Here we can trust the compiler to automatically set them to zero.
> The variable has since been uninitialized.
>
> Signed-off-by: Jules Irenge
> ---
> kernel/audit.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
In general this is fine, but it will have to wait until after the
merge window closes.
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 7b1a38a211a9..7d79ecb58b01 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -311,8 +311,8 @@ void audit_panic(const char *message)
>
> static inline int audit_rate_check(void)
> {
> - static unsigned longlast_check = 0;
> - static int messages = 0;
> + static unsigned longlast_check;
> + static int messages;
> static DEFINE_SPINLOCK(lock);
> unsigned long flags;
> unsigned long now;
> @@ -348,7 +348,7 @@ static inline int audit_rate_check(void)
> */
> void audit_log_lost(const char *message)
> {
> - static unsigned longlast_msg = 0;
> + static unsigned longlast_msg;
> static DEFINE_SPINLOCK(lock);
> unsigned long flags;
> unsigned long now;
> @@ -713,7 +713,7 @@ static int kauditd_send_queue(struct sock *sk, u32 portid,
> {
> int rc = 0;
> struct sk_buff *skb;
> - static unsigned int failed = 0;
> + static unsigned int failed;
>
> /* NOTE: kauditd_thread takes care of all our locking, we just use
> * the netlink info passed to us (e.g. sk and portid) */
> --
> 2.26.2
--
paul moore
www.paul-moore.com
Re: [Linux-kernel-mentees] [PATCH v3] ptrace: Prevent kernel-infoleak in ptrace_get_syscall_info()
On Sat, Aug 01, 2020 at 07:08:19PM +0300, Dmitry V. Levin wrote:
> On Sat, Aug 01, 2020 at 11:20:44AM -0400, Peilin Ye wrote:
> > ptrace_get_syscall_info() is potentially copying uninitialized stack
> > memory to userspace, since the compiler may leave a 3-byte hole near the
> > beginning of `info`. Fix it by adding a padding field to `struct
> > ptrace_syscall_info`.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 201766a20e30 ("ptrace: add PTRACE_GET_SYSCALL_INFO request")
> > Suggested-by: Dan Carpenter
> > Signed-off-by: Peilin Ye
> > ---
> > Change in v3:
> > - Remove unnecessary `__aligned__` attribute. (Suggested by
> > Dmitry V. Levin )
> >
> > Change in v2:
> > - Add a padding field to `struct ptrace_syscall_info`, instead of
> > doing memset() on `info`. (Suggested by Dmitry V. Levin
> > )
> >
> > Reference: https://lwn.net/Articles/417989/
> >
> > $ # before:
> > $ pahole -C "ptrace_syscall_info" kernel/ptrace.o
> > struct ptrace_syscall_info {
> > __u8 op; /* 0 1 */
> >
> > /* XXX 3 bytes hole, try to pack */
> >
> > __u32 arch __attribute__((__aligned__(4))); /*
> > 4 4 */
> > __u64 instruction_pointer; /* 8 8 */
> > __u64 stack_pointer;/*16 8 */
> > union {
> > struct {
> > __u64 nr; /*24 8 */
> > __u64 args[6]; /*3248 */
> > } entry; /*2456 */
> > struct {
> > __s64 rval; /*24 8 */
> > __u8 is_error; /*32 1 */
> > } exit; /*2416 */
> > struct {
> > __u64 nr; /*24 8 */
> > __u64 args[6]; /*3248 */
> > /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago
> > --- */
> > __u32 ret_data; /*80 4 */
> > } seccomp; /*2464 */
> > }; /*2464 */
> >
> > /* size: 88, cachelines: 2, members: 5 */
> > /* sum members: 85, holes: 1, sum holes: 3 */
> > /* forced alignments: 1, forced holes: 1, sum forced holes: 3 */
> > /* last cacheline: 24 bytes */
> > } __attribute__((__aligned__(8)));
> > $
> > $ # after:
> > $ pahole -C "ptrace_syscall_info" kernel/ptrace.o
> > struct ptrace_syscall_info {
> > __u8 op; /* 0 1 */
> > __u8 pad[3]; /* 1 3 */
> > __u32 arch; /* 4 4 */
> > __u64 instruction_pointer; /* 8 8 */
> > __u64 stack_pointer;/*16 8 */
> > union {
> > struct {
> > __u64 nr; /*24 8 */
> > __u64 args[6]; /*3248 */
> > } entry; /*2456 */
> > struct {
> > __s64 rval; /*24 8 */
> > __u8 is_error; /*32 1 */
> > } exit; /*2416 */
> > struct {
> > __u64 nr; /*24 8 */
> > __u64 args[6]; /*3248 */
> > /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago
> > --- */
> > __u32 ret_data; /*80 4 */
> > } seccomp; /*2464 */
> > }; /*2464 */
> >
> > /* size: 88, cachelines: 2, members: 6 */
> > /* last cacheline: 24 bytes */
> > };
> > $ _
> >
> > include/uapi/linux/ptrace.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> > index a71b6e3b03eb..83ee45fa634b 100644
> > --- a/include/uapi/linux/ptrace.h
> > +++ b/include/uapi/linux/ptrace.h
> > @@ -81,7 +81,8 @@ struct seccomp_metadata {
> >
> > struct ptrace_syscall_info {
> > __u8 op;/* PTRACE_SYSCALL_INFO_* */
> > - __u32 arch __attribute__((__aligned__(sizeof(__u32;
> > + __u8 pad[3];
> > + __u32 arch;
> > __u64 instruction_pointer;
> > __u64 stack_pointer;
> > union {
>
> Reviewed-by: Dmitry V. Levin
Acked-by: Christian Brauner
Oh fun.
I'd pick this up and run the ptrace tests that we have for
[PATCH] arm64: dts: rockchip: enable HDMI sound nodes for rk3328-rock64
This patch enables HDMI sound (I2S0) and Analog sound (I2S1) which
are defined in rk3328.dtsi, and replace SPDIF nodes.
We can use SPDIF passthrough with suitable ALSA settings and on
mpv or other media players.
- Settings:
https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/filesystem/usr/share/alsa/cards/SPDIF.conf
- Ex.: mpv foo.ac3 --audio-spdif=ac3
--audio-device='alsa/SPDIF.pcm.iec958.0:SPDIF'
[Why use simple-audio-card for SPDIF?]
For newly adding nodes, ASoC guys recommend to use audio-graph-card.
But all other sound nodes for rk3328 have already been defined by
simple-audio-card. In this time, I chose consistency of sound nodes.
[DMA allocation problem]
After apply this patch, UART2 will fail to allocate DMA resources
but UART driver can work fine without DMA.
This error is related to the DMAC of rk3328 (pl330 or compatible).
DMAC connected to 16 DMA sources. Each sources have ID number that is
called 'Req number' in rk3328 TRM. After apply this patch total 7
sources will be activated as follows:
| Req number | Source | Required |
||| channels |
|++---|
| 8, 9 | SPI0 | 2ch |
| 11, 12 | I2S0 | 2ch |
| 14, 15 | I2S1 | 2ch |
| 10 | SPDIF | 1ch |
|++---|
|| Total | 7ch |
|++---|
| 6, 7 | UART2 | 2ch | -> cannot get DMA channels
Due to rk3328 DMAC specification we can use max 8 channels at same
time. If SPI0/I2S0/I2S1/SPDIF will be activated by this patch,
required DMAC channels reach to 7. So last two channels (for UART2)
cannot get DMA resources.
Virt-dma mechanism for pl0330 DMAC driver is needed to fix this
problem.
Signed-off-by: Katsuhiro Suzuki
---
.../arm64/boot/dts/rockchip/rk3328-rock64.dts | 58 +--
1 file changed, 26 insertions(+), 32 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 86cfb5c50a94..4608f8fc6ff3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -84,34 +84,34 @@ standby_led: led-1 {
};
};
- sound {
- compatible = "audio-graph-card";
- label = "rockchip,rk3328";
- dais = <&i2s1_p0
- &spdif_p0>;
+ spdif_sound: spdif-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "SPDIF";
+ status = "okay";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_dit>;
+ };
};
- spdif-dit {
+ spdif_dit: spdif-dit {
compatible = "linux,spdif-dit";
#sound-dai-cells = <0>;
-
- port {
- dit_p0_0: endpoint {
- remote-endpoint = <&spdif_p0_0>;
- };
- };
+ status = "okay";
};
};
+&analog_sound {
+ status = "okay";
+};
+
&codec {
mute-gpios = <&grf_gpio 0 GPIO_ACTIVE_LOW>;
status = "okay";
-
- port@0 {
- codec_p0_0: endpoint {
- remote-endpoint = <&i2s1_p0_0>;
- };
- };
};
&cpu0 {
@@ -163,6 +163,10 @@ &hdmi {
status = "okay";
};
+&hdmi_sound {
+ status = "okay";
+};
+
&hdmiphy {
status = "okay";
};
@@ -278,16 +282,12 @@ regulator-state-mem {
};
};
-&i2s1 {
+&i2s0 {
status = "okay";
+};
- i2s1_p0: port {
- i2s1_p0_0: endpoint {
- dai-format = "i2s";
- mclk-fs = <256>;
- remote-endpoint = <&codec_p0_0>;
- };
- };
+&i2s1 {
+ status = "okay";
};
&io_domains {
@@ -337,12 +337,6 @@ &sdmmc {
&spdif {
pinctrl-0 = <&spdifm0_tx>;
status = "okay";
-
- spdif_p0: port {
- spdif_p0_0: endpoint {
- remote-endpoint = <&dit_p0_0>;
- };
- };
};
&spi0 {
--
2.27.0
[Linux-kernel-mentees] [PATCH net] net/smc: Prevent kernel-infoleak in __smc_diag_dump()
__smc_diag_dump() is potentially copying uninitialized kernel stack memory
into socket buffers, since the compiler may leave a 4-byte hole near the
beginning of `struct smcd_diag_dmbinfo`. Fix it by initializing `dinfo`
with memset().
Cc: sta...@vger.kernel.org
Fixes: 4b1b7d3b30a6 ("net/smc: add SMC-D diag support")
Suggested-by: Dan Carpenter
Signed-off-by: Peilin Ye
---
Reference: https://lwn.net/Articles/417989/
$ pahole -C "smcd_diag_dmbinfo" net/smc/smc_diag.o
struct smcd_diag_dmbinfo {
__u32 linkid; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
__u64 peer_gid __attribute__((__aligned__(8))); /*
8 8 */
__u64 my_gid __attribute__((__aligned__(8))); /*
16 8 */
__u64 token __attribute__((__aligned__(8))); /*
24 8 */
__u64 peer_token __attribute__((__aligned__(8)));
/*32 8 */
/* size: 40, cachelines: 1, members: 5 */
/* sum members: 36, holes: 1, sum holes: 4 */
/* forced alignments: 4, forced holes: 1, sum forced holes: 4 */
/* last cacheline: 40 bytes */
} __attribute__((__aligned__(8)));
$ _
net/smc/smc_diag.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/net/smc/smc_diag.c b/net/smc/smc_diag.c
index e1f64f4ba236..da9ba6d1679b 100644
--- a/net/smc/smc_diag.c
+++ b/net/smc/smc_diag.c
@@ -170,13 +170,15 @@ static int __smc_diag_dump(struct sock *sk, struct
sk_buff *skb,
(req->diag_ext & (1 << (SMC_DIAG_DMBINFO - 1))) &&
!list_empty(&smc->conn.lgr->list)) {
struct smc_connection *conn = &smc->conn;
- struct smcd_diag_dmbinfo dinfo = {
- .linkid = *((u32 *)conn->lgr->id),
- .peer_gid = conn->lgr->peer_gid,
- .my_gid = conn->lgr->smcd->local_gid,
- .token = conn->rmb_desc->token,
- .peer_token = conn->peer_token
- };
+ struct smcd_diag_dmbinfo dinfo;
+
+ memset(&dinfo, 0, sizeof(dinfo));
+
+ dinfo.linkid = *((u32 *)conn->lgr->id);
+ dinfo.peer_gid = conn->lgr->peer_gid;
+ dinfo.my_gid = conn->lgr->smcd->local_gid;
+ dinfo.token = conn->rmb_desc->token;
+ dinfo.peer_token = conn->peer_token;
if (nla_put(skb, SMC_DIAG_DMBINFO, sizeof(dinfo), &dinfo) < 0)
goto errout;
--
2.25.1
Re: [PATCH 0/3] Add 3 new keycodes and use them for 3 new hotkeys on new Lenovo Thinkpads
On Mon, 27 Jul 2020, Andy Shevchenko wrote: > On Mon, Jul 27, 2020 at 10:49 AM Andy Shevchenko > wrote: > > On Mon, Jul 27, 2020 at 10:45 AM Hans de Goede wrote: > > > > > > Hi, > > > > > > On 7/27/20 2:50 AM, Henrique de Moraes Holschuh wrote: > > > > On Tue, 21 Jul 2020, Dmitry Torokhov wrote: > > > >> On Sun, Jul 19, 2020 at 07:56:49PM -0300, Henrique de Moraes Holschuh > > > >> wrote: > > > >>> On Fri, 17 Jul 2020, Hans de Goede wrote: > > > This is a simple patch-series adding support for 3 new hotkeys found > > > on various new Lenovo Thinkpad models. > > > >>> > > > >>> For all three patches, pending an ack for the new keycodes by the > > > >>> input > > > >>> maintainers: > > > >>> > > > >>> Acked-by: Henrique de Moraes Holschuh > > > >> > > > >> Do you want me to merge all 3 through input tree? > > > > > > > > Hans, Daren, Andy, what do you prefer? > > > > > > Taking all this upstream through Dmitry's input tree is fine with > > > me, but this really is up to Andy and/or Daren. > > > > Fine with me. > > To be clear, I assume it will go thru input tree. > If my formal tag needed, use > Acked-by: Andy Shevchenko Also, Acked-by: Henrique de Moraes Holschuh -- Henrique Holschuh
Re: [PATCH] drm/vkms: modify sequence disable/plane/enable in commit_tail
On Wed, Jul 29, 2020 at 12:22 PM Sidong Yang wrote:
>
> This patch modifies function call sequence in commit tail. This is for
> the problem that raised when kms_cursor_crc test is tested repeatedly.
> In second test, there is an bug that crtc commit doesn't start vblank events.
> Because there is some error about vblank's refcount. in commit_flush() that
> called from commit_plane, drm_vblank_get() is called and vblank is enabled
> in normal case. But in second test, vblank isn't enable for vblank->refcount
> is already increased in previous test. Increased refcount will be decreased
> in drm_atomic_helper_commit_modeset_enables() after commit_plane.
> Therefore, commit_plane should be called after commit_modeset_enable.
>
> In this situation, there is a warning raised in get_vblank_timestamp().
> hrtimer.node.expires and vblank->time are zero for no vblank events before.
> This patch returns current time when vblank is not enabled.
>
Hi Sidong,
I think this patch tries to solve two different issues.
I am not a maintainer, but I believe you can split it.
Everything indicates that changing the commit tail sequence does not
ideally solve the problem of subtests getting stuck (as we have dicussed);
however, for me, the treatment of the warning is valid and it is also related
to other IGT tests using VKMS.
One option is to send a patch that only treats the warning. I believe that
in the body of the commit message, it would be nice to have the warning
that this patch addresses, and when it appears by running an IGT test.
Also, say why it should be done this way in vkms.
This info could help future debugging.
Off-topic: I removed the group's mailing list of the University of São
Paulo (kernel-usp) from the cc, since I believe you had no intention of
sending the patch to them.
Best regards,
Melissa
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
>
> Signed-off-by: Sidong Yang
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
> drivers/gpu/drm/vkms/vkms_drv.c | 4 ++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..09c012d54d58 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc
> *crtc,
> struct vkms_output *output = &vkmsdev->output;
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>
> + if (!READ_ONCE(vblank->enabled)) {
> + *vblank_time = ktime_get();
> + return true;
> + }
> +
> *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
>
> if (WARN_ON(*vblank_time == vblank->time))
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 1e8b2169d834..c2c83a01d4a7 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -76,10 +76,10 @@ static void vkms_atomic_commit_tail(struct
> drm_atomic_state *old_state)
>
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
>
> - drm_atomic_helper_commit_planes(dev, old_state, 0);
> -
> drm_atomic_helper_commit_modeset_enables(dev, old_state);
>
> + drm_atomic_helper_commit_planes(dev, old_state, 0);
> +
> drm_atomic_helper_fake_vblank(old_state);
>
> drm_atomic_helper_commit_hw_done(old_state);
> --
> 2.17.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kernel USP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kernel-usp+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kernel-usp/20200729152231.13249-1-realwakka%40gmail.com.
Re: [PATCH 2/2] habanalabs: add information about PCIe controller
Hi Oded,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[cannot apply to linux/master linus/master v5.8-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Oded-Gabbay/habanalabs-Replace-dma-fence-mechanism-with-completions/20200730-211536
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
22362aa30bad6f03b5bcbbeee3cdc61950d40086
config: x86_64-randconfig-s022-20200801 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-115-g5fc204f2-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/misc/habanalabs/common/firmware_if.c:368:19: sparse: sparse:
>> incorrect type in assignment (different base types) @@ expected
>> restricted __le32 [assigned] [usertype] index @@ got restricted __le64
>> [usertype] @@
>> drivers/misc/habanalabs/common/firmware_if.c:368:19: sparse: expected
>> restricted __le32 [assigned] [usertype] index
>> drivers/misc/habanalabs/common/firmware_if.c:368:19: sparse: got
>> restricted __le64 [usertype]
>> drivers/misc/habanalabs/common/firmware_if.c:379:19: sparse: sparse:
>> incorrect type in assignment (different base types) @@ expected
>> restricted __le32 [addressable] [assigned] [usertype] index @@ got
>> restricted __le64 [usertype] @@
>> drivers/misc/habanalabs/common/firmware_if.c:379:19: sparse: expected
>> restricted __le32 [addressable] [assigned] [usertype] index
drivers/misc/habanalabs/common/firmware_if.c:379:19: sparse: got
restricted __le64 [usertype]
vim +368 drivers/misc/habanalabs/common/firmware_if.c
356
357 int hl_fw_armcp_pci_counters_get(struct hl_device *hdev,
358 struct hl_info_pci_counters *counters)
359 {
360 struct armcp_packet pkt = {};
361 long result;
362 int rc;
363
364 pkt.ctl = cpu_to_le32(ARMCP_PACKET_PCIE_THROUGHPUT_GET <<
365 ARMCP_PKT_CTL_OPCODE_SHIFT);
366
367 /* Fetch PCI rx counter */
> 368 pkt.index = cpu_to_le64(armcp_pcie_throughput_rx);
369 rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) &pkt,
sizeof(pkt),
370 HL_ARMCP_INFO_TIMEOUT_USEC,
&result);
371 if (rc) {
372 dev_err(hdev->dev,
373 "Failed to handle ArmCP PCI info pkt, error
%d\n", rc);
374 return rc;
375 }
376 counters->rx_throughput = result;
377
378 /* Fetch PCI tx counter */
> 379 pkt.index = cpu_to_le64(armcp_pcie_throughput_tx);
380 rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) &pkt,
sizeof(pkt),
381 HL_ARMCP_INFO_TIMEOUT_USEC,
&result);
382 if (rc) {
383 dev_err(hdev->dev,
384 "Failed to handle ArmCP PCI info pkt, error
%d\n", rc);
385 return rc;
386 }
387 counters->tx_throughput = result;
388
389 /* Fetch PCI replay counter */
390 pkt.ctl = cpu_to_le32(ARMCP_PACKET_PCIE_REPLAY_CNT_GET <<
391 ARMCP_PKT_CTL_OPCODE_SHIFT);
392
393 rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) &pkt,
sizeof(pkt),
394 HL_ARMCP_INFO_TIMEOUT_USEC, &result);
395 if (rc) {
396 dev_err(hdev->dev,
397 "Failed to handle ArmCP PCI info pkt, error
%d\n", rc);
398 return rc;
399 }
400 counters->replay_cnt = (u32) result;
401
402 return rc;
403 }
404
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v7] Makefile: Add clang-tidy and static analyzer support to makefile
On Tue, 28 Jul 2020, 'Nathan Huckleberry' via Clang Built Linux wrote:
> This patch adds clang-tidy and the clang static-analyzer as make
> targets. The goal of this patch is to make static analysis tools
> usable and extendable by any developer or researcher who is familiar
> with basic c++.
>
> The current static analysis tools require intimate knowledge of the
> internal workings of the static analysis. Clang-tidy and the clang
> static analyzers expose an easy to use api and allow users unfamiliar
> with clang to write new checks with relative ease.
>
> ===Clang-tidy===
>
> Clang-tidy is an easily extendable 'linter' that runs on the AST.
> Clang-tidy checks are easy to write and understand. A check consists of
> two parts, a matcher and a checker. The matcher is created using a
> domain specific language that acts on the AST
> (https://clang.llvm.org/docs/LibASTMatchersReference.html). When AST
> nodes are found by the matcher a callback is made to the checker. The
> checker can then execute additional checks and issue warnings.
>
> Here is an example clang-tidy check to report functions that have calls
> to local_irq_disable without calls to local_irq_enable and vice-versa.
> Functions flagged with __attribute((annotation("ignore_irq_balancing")))
> are ignored for analysis. (https://reviews.llvm.org/D65828)
>
> ===Clang static analyzer===
>
> The clang static analyzer is a more powerful static analysis tool that
> uses symbolic execution to find bugs. Currently there is a check that
> looks for potential security bugs from invalid uses of kmalloc and
> kfree. There are several more general purpose checks that are useful for
> the kernel.
>
> The clang static analyzer is well documented and designed to be
> extensible.
> (https://clang-analyzer.llvm.org/checker_dev_manual.html)
> (https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf)
>
> The main draw of the clang tools is how accessible they are. The clang
> documentation is very nice and these tools are built specifically to be
> easily extendable by any developer. They provide an accessible method of
> bug-finding and research to people who are not overly familiar with the
> kernel codebase.
>
> Signed-off-by: Nathan Huckleberry
Hi Nathan, Hi Nick,
I have been busy with other topics around the kernel and static analysis;
but then, I read clang and static analysis in my mailbox in this patch.
So, I thought let me give this patch a try on the weekend.
I applied the patch on next-2020729; that worked.
Then:
$ make clang-tidy
scripts/clang-tools/Makefile.clang-tools:13: *** clang-tidy requires
CC=clang. Stop.
Okay, that is a good and clear error message.
Then:
$ make CC=clang-10 defconfig
$ make CC=clang-10 clang-tidy
python3 scripts/clang-tools/gen_compile_commands.py
WARNING: Found 8 entries. Have you compiled the kernel?
python3 scripts/clang-tools/run-clang-tools.py clang-tidy
compile_commands.json
Then actually an error in clang-tidy.
Error: no checks enabled.
USAGE: clang-tidy [options] [... ]
...
I will get to that later how I fixed that for my setup.
Okay, good, that is clear... I need to compile it first, got it.
$ make CC=clang-10
$ make CC=clang-10 clang-tidy
Okay, I run except for the fix I needed.
Where is the output from clang-tidy?
It prints:
python3 scripts/clang-tools/gen_compile_commands.py
python3 scripts/clang-tools/run-clang-tools.py clang-tidy compile_commands.json
That is it. Does that mean 0 warnings, or where do I find the output?
The script suggests it should be in stderr once all the parallel runs
collected it, right?
I was confused; maybe a short summary output might help here.
Then, I ran
$ make CC=clang-10 clang-analyzer
And I see a lot of warnings... I guess that is intended.
There is a lot of:
Suppressed XX warnings (XX in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use
-system-headers to display errors from system headers as well.
To an outsider, it is unclear if that is intended or if the tool is broken
in this setup.
Is there are way to silent that meta-warning? Or is my setup broken?
In summary, it is pretty clear how to run clang-tidy and clang-analyzer
and it was a pretty smooth experience, even with no documentation at hand.
It was fun for me. Keep up the good work!
Just one issue... see below.
> ---
> Changes v6->v7
> * Fix issues with relative paths
> * Additional style fixes
> MAINTAINERS | 1 +
> Makefile | 3 +
> scripts/clang-tools/Makefile.clang-tools | 23 ++
> .../{ => clang-tools}/gen_compile_commands.py | 0
> scripts/clang-tools/run-clang-tools.py| 74 +++
> 5 files changed, 101 insertions(+)
> create mode 100644 scripts/clang-tools/Makefile.clang-tools
> rename scripts/{ => clang-tools}/gen_compile_commands.py (100%)
> create mode 100755 scripts/clang
Re: [PATCH] f2fs: fix deadlock between quota writes and checkpoint
On Wed, Jul 29, 2020 at 12:02:44AM -0700, Jaegeuk Kim wrote: > f2fs_write_data_pages(quota_mapping) > __f2fs_write_data_pages f2fs_write_checkpoint > * blk_start_plug(&plug); > * add bio in write_io[DATA] > - block_operations > - skip syncing quota by > > >DEFAULT_RETRY_QUOTA_FLUSH_COUNT > - down_write(&sbi->node_write); > - f2fs_write_single_data_page > - f2fs_do_write_data_page > - f2fs_outplace_write_data > - do_write_page >- f2fs_allocate_data_block > - down_write(node_write) > - > f2fs_wait_on_all_pages(F2FS_WB_CP_DATA); > > Signed-off-by: Daeho Jeong > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/checkpoint.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > index 8c782d3f324f0..99c8061da55b9 100644 > --- a/fs/f2fs/checkpoint.c > +++ b/fs/f2fs/checkpoint.c > @@ -1269,6 +1269,8 @@ void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, > int type) > if (type == F2FS_DIRTY_META) > f2fs_sync_meta_pages(sbi, META, LONG_MAX, > FS_CP_META_IO); > + else if (type == F2FS_WB_CP_DATA) > + f2fs_submit_merged_write(sbi, DATA); > io_schedule_timeout(DEFAULT_IO_TIMEOUT); > } > finish_wait(&sbi->cp_wait, &wait); This patch is causing the following WARNING when I try to run xfstests: [ 20.157753] [ cut here ] [ 20.158393] do not call blocking ops when !TASK_RUNNING; state=2 set at [<96354225>] prepare_to_wait+0xcd/0x430 [ 20.159858] WARNING: CPU: 1 PID: 1152 at kernel/sched/core.c:7142 __might_sleep+0x149/0x1a0 [ 20.160762] Modules linked in: [ 20.161119] CPU: 1 PID: 1152 Comm: umount Not tainted 5.8.0-rc7-next-20200731 #1 [ 20.161924] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20200516_175120-felixonmars2 04/01/2014 [ 20.163110] RIP: 0010:__might_sleep+0x149/0x1a0 [ 20.163709] Code: 65 48 8b 1c 25 c0 ed 01 00 48 8d 7b 10 48 89 fe 48 c1 ee 03 80 3c 06 00 75 2b 48 8b 73 10 48 c7 c7 a0 bc 66 83 e8 0 [ 20.166083] RSP: 0018:c900015a7868 EFLAGS: 00010286 [ 20.166759] RAX: RBX: 88806805c500 RCX: [ 20.167658] RDX: 0004 RSI: 0008 RDI: f520002b4eff [ 20.168557] RBP: c900015a7898 R08: 0001 R09: 88806d32f44f [ 20.169481] R10: ed100da65e89 R11: 11100d00b9a1 R12: 83674ba0 [ 20.170389] R13: 05fa R14: R15: 8880638200a0 [ 20.171291] FS: 7f3da4b2f080() GS:88806d30() knlGS: [ 20.172311] CS: 0010 DS: ES: CR0: 80050033 [ 20.173061] CR2: 55734e8b2638 CR3: 67069000 CR4: 003506e0 [ 20.173965] Call Trace: [ 20.174295] ? lockdep_hardirqs_on_prepare.part.0+0x22f/0x430 [ 20.175022] down_write+0x77/0x150 [ 20.175464] ? rwsem_down_read_slowpath+0xd40/0xd40 [ 20.176110] __submit_merged_write_cond+0x191/0x310 [ 20.176739] f2fs_submit_merged_write+0x18/0x20 [ 20.177323] f2fs_wait_on_all_pages+0x269/0x2d0 [ 20.177899] ? block_operations+0x980/0x980 [ 20.178441] ? __kasan_check_read+0x11/0x20 [ 20.178975] ? finish_wait+0x260/0x260 [ 20.179488] ? percpu_counter_set+0x147/0x230 [ 20.180049] do_checkpoint+0x1757/0x2a50 [ 20.180558] f2fs_write_checkpoint+0x840/0xaf0 [ 20.181126] f2fs_sync_fs+0x287/0x4a0 [ 20.181602] ? kill_f2fs_super+0x310/0x310 [ 20.182127] ? dput+0x3bf/0x570 [ 20.182565] sync_filesystem+0x165/0x200 [ 20.183075] generic_shutdown_super+0x69/0x320 [ 20.183651] kill_block_super+0x97/0xe0 [ 20.184144] kill_f2fs_super+0x21f/0x310 [ 20.184656] ? f2fs_dquot_commit+0xc0/0xc0 [ 20.185179] ? kfree+0xcc/0x320 [ 20.185594] ? unregister_shrinker+0x163/0x220 [ 20.186185] deactivate_locked_super+0x7b/0xf0 [ 20.186763] deactivate_super+0x71/0x80 [ 20.187262] cleanup_mnt+0x362/0x540 [ 20.187722] __cleanup_mnt+0xd/0x10 [ 20.188172] task_work_run+0xca/0x170 [ 20.188647] exit_to_user_mode_loop+0x98/0xa0 [ 20.189226] exit_to_user_mode_prepare+0xb4/0x110 [ 20.189838] syscall_exit_to_user_mode+0x37/0x90 [ 20.190435] do_syscall_64+0x3f/0x50 [ 20.190895] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 20.191539] RIP: 0033:0x7f3da4f55507 [ 20.192000] Code: 19 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 8 [ 20.194359] RSP: 002b:7ffc043b0018 EFLAGS: 0246 ORIG_RAX: 00a6 [ 20.195319] RAX: RBX: 55fbd27c6970 RCX: 7f3da4f55507 [ 20.196239] RDX: 0001 RSI: RDI: 55
Re: [PATCH v7 1/2] tmpfs: Per-superblock i_ino support
On Mon, 13 Jul 2020, Chris Down wrote:
> get_next_ino has a number of problems:
>
> - It uses and returns a uint, which is susceptible to become overflowed
> if a lot of volatile inodes that use get_next_ino are created.
> - It's global, with no specificity per-sb or even per-filesystem. This
> means it's not that difficult to cause inode number wraparounds on a
> single device, which can result in having multiple distinct inodes
> with the same inode number.
>
> This patch adds a per-superblock counter that mitigates the second case.
> This design also allows us to later have a specific i_ino size
> per-device, for example, allowing users to choose whether to use 32- or
> 64-bit inodes for each tmpfs mount. This is implemented in the next
> commit.
>
> For internal shmem mounts which may be less tolerant to spinlock delays,
> we implement a percpu batching scheme which only takes the stat_lock at
> each batch boundary.
>
> Signed-off-by: Chris Down
> Cc: Amir Goldstein
> Cc: Hugh Dickins
Acked-by: Hugh Dickins
Thanks for coming back and completing this, Chris.
Some comments below, nothing to detract from that Ack, more notes to
myself: things I might change slightly when I get back here later on.
I'm glad to see Andrew pulled your 0/2 text into this 1/2.
> Cc: Andrew Morton
> Cc: Al Viro
> Cc: Matthew Wilcox
> Cc: Jeff Layton
> Cc: Johannes Weiner
> Cc: Tejun Heo
> Cc: linux...@kvack.org
> Cc: linux-fsde...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: kernel-t...@fb.com
> ---
> include/linux/fs.h | 15 +
> include/linux/shmem_fs.h | 2 ++
> mm/shmem.c | 66 +---
> 3 files changed, 78 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index f15848899945..b70b334f8e16 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2961,6 +2961,21 @@ extern void discard_new_inode(struct inode *);
> extern unsigned int get_next_ino(void);
> extern void evict_inodes(struct super_block *sb);
>
> +/*
> + * Userspace may rely on the the inode number being non-zero. For example,
> glibc
> + * simply ignores files with zero i_ino in unlink() and other places.
> + *
> + * As an additional complication, if userspace was compiled with
> + * _FILE_OFFSET_BITS=32 on a 64-bit kernel we'll only end up reading out the
> + * lower 32 bits, so we need to check that those aren't zero explicitly. With
> + * _FILE_OFFSET_BITS=64, this may cause some harmless false-negatives, but
> + * better safe than sorry.
> + */
> +static inline bool is_zero_ino(ino_t ino)
> +{
> + return (u32)ino == 0;
> +}
Hmm, okay. The value of this unnecessary, and inaccurately named,
wrapper is in the great comment above it: which then suffers a bit
from being hidden away in a header file. I'd understand its placing
better if you had also changed get_next_ino() to use it.
And I have another reason for wondering whether this function is
the right thing to abstract out: 1 is also somewhat special, being
the ino of the root. It seems a little unfortunate, when we recycle
through the 32-bit space, to reuse the one ino that is certain to be
still in use (maybe all the others get "rm -rf"ed every day). But
I haven't yet decided whether that's worth bothering about at all.
> +
> extern void __iget(struct inode * inode);
> extern void iget_failed(struct inode *);
> extern void clear_inode(struct inode *);
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index 7a35a6901221..eb628696ec66 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -36,6 +36,8 @@ struct shmem_sb_info {
> unsigned char huge; /* Whether to try for hugepages */
> kuid_t uid; /* Mount uid for root directory */
> kgid_t gid; /* Mount gid for root directory */
> + ino_t next_ino; /* The next per-sb inode number to use */
> + ino_t __percpu *ino_batch; /* The next per-cpu inode number to use */
> struct mempolicy *mpol; /* default memory policy for mappings */
> spinlock_t shrinklist_lock; /* Protects shrinklist */
> struct list_head shrinklist; /* List of shinkable inodes */
> diff --git a/mm/shmem.c b/mm/shmem.c
> index a0dbe62f8042..0ae250b4da28 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -260,18 +260,67 @@ bool vma_is_shmem(struct vm_area_struct *vma)
> static LIST_HEAD(shmem_swaplist);
> static DEFINE_MUTEX(shmem_swaplist_mutex);
>
> -static int shmem_reserve_inode(struct super_block *sb)
> +/*
> + * shmem_reserve_inode() performs bookkeeping to reserve a shmem inode, and
> + * produces a novel ino for the newly allocated inode.
> + *
> + * It may also be called when making a hard link to permit the space needed
> by
> + * each dentry. However, in that case, no new inode number is needed since
> that
> + * internally draws from another pool of inode numbers (currently gl
Re: [PATCH 0/4] Checkpatch tool errors clean up
On Sat, 2020-08-01 at 19:45 +0100, Jules Irenge wrote: > Hi > I am proposing these 4 patches. > I am currently learning the core kernel the hard way. > I will appreciate any feedback negative or positive. > Thanks Generally, whitespace only changes outside of drivers/staging are not encouraged. > Jules Irenge (4): > acct: Add required space between variable and operator > audit: uninitialize global variable audit_sig_sid > audit: uninitialize static variables > context_tracking: uninitialize static variables > > kernel/acct.c | 2 +- > kernel/audit.c| 10 +- > kernel/context_tracking.c | 2 +- > 3 files changed, 7 insertions(+), 7 deletions(-) >
[GIT PULL] Fourth batch of perf tooling fixes for v5.8
Hi Linus, Please consider pulling, Best regards, - Arnaldo The following changes since commit d8b9faec54ae4bc2fff68bcd0befa93ace8256ce: Merge tag 'drm-fixes-2020-07-31' of git://anongit.freedesktop.org/drm/drm (2020-07-30 21:26:42 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-tools-fixes-2020-08-01 for you to fetch changes up to 39efdd94e314336f4acbac4c07e0f37bdc3bef71: libtraceevent: Fix build with binutils 2.35 (2020-07-31 09:31:55 -0300) Fourth batch of perf tooling fixes for v5.8: - Fix libtraceevent build with binutils 2.35. - Fix memory leak in process_dynamic_array_len in libtraceevent. - Fix 'perf test 68' zstd compression for s390. - Fix record failure when mixed with ARM SPE event. Signed-off-by: Arnaldo Carvalho de Melo Ben Hutchings (1): libtraceevent: Fix build with binutils 2.35 Philippe Duplessis-Guindon (1): tools lib traceevent: Fix memory leak in process_dynamic_array_len Thomas Richter (1): perf tests: Fix test 68 zstd compression for s390 Wei Li (1): perf tools: Fix record failure when mixed with ARM SPE event tools/lib/traceevent/event-parse.c| 1 + tools/lib/traceevent/plugins/Makefile | 2 +- tools/perf/arch/arm/util/auxtrace.c | 8 tools/perf/tests/shell/record+zstd_comp_decomp.sh | 3 ++- 4 files changed, 8 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit declaration of function 'enable_kernel_vsx'; did you mean
Hi Timothy,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 7dc6fd0f3b8404542718039f5de19fe56e474578
commit: 16a9dea110a67d62401ffeac4828cabdedec7548 amdgpu: Enable initial DCN
support on POWER
date: 8 months ago
config: powerpc64-randconfig-r015-20200801 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 16a9dea110a67d62401ffeac4828cabdedec7548
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function
'dcn_bw_apply_registry_override':
drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:62:6: error: implicit
declaration of function 'cpu_has_feature'; did you mean 'mmu_has_feature'?
[-Werror=implicit-function-declaration]
62 | if (cpu_has_feature(CPU_FTR_VSX_COMP)) { \
| ^~~
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:626:2: note: in
expansion of macro 'DC_FP_START'
626 | DC_FP_START();
| ^~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit
>> declaration of function 'enable_kernel_vsx'; did you mean
>> 'enable_kernel_fp'? [-Werror=implicit-function-declaration]
64 | enable_kernel_vsx(); \
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:626:2: note: in
expansion of macro 'DC_FP_START'
626 | DC_FP_START();
| ^~~
drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:67:3: error: implicit
declaration of function 'enable_kernel_altivec'; did you mean
'enable_kernel_fp'? [-Werror=implicit-function-declaration]
67 | enable_kernel_altivec(); \
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:626:2: note: in
expansion of macro 'DC_FP_START'
626 | DC_FP_START();
| ^~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit
>> declaration of function 'disable_kernel_vsx'; did you mean
>> 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
75 | disable_kernel_vsx(); \
| ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:662:2: note: in
expansion of macro 'DC_FP_END'
662 | DC_FP_END();
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:78:3: error: implicit
declaration of function 'disable_kernel_altivec'; did you mean
'disable_kernel_fp'? [-Werror=implicit-function-declaration]
78 | disable_kernel_altivec(); \
| ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:662:2: note: in
expansion of macro 'DC_FP_END'
662 | DC_FP_END();
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: At top level:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:706:14: warning:
no previous prototype for 'get_highest_allowed_voltage_level'
[-Wmissing-prototypes]
706 | unsigned int get_highest_allowed_voltage_level(uint32_t
hw_internal_rev)
| ^
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/core_types.h:32,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/resource.h:28,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:32:
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:124:22:
warning: 'DP_DVI_CONVERTER_ID_4' defined but not used [-Wunused-const-variable=]
124 | static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
| ^
drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:122:22:
warning: 'DP_VGA_LVDS_CONVERTER_ID_3' defined but not used
[-Wunused-const-variable=]
122 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
| ^~
Re: [PATCH 2/4] audit: uninitialize global variable audit_sig_sid
On Sat, 2020-08-01 at 19:46 +0100, Jules Irenge wrote: > Checkpatch tool reports an error at variable audit_sig_sid declaration [] > diff --git a/kernel/audit.c b/kernel/audit.c [] > @@ -125,7 +125,7 @@ static u32audit_backlog_wait_time = > AUDIT_BACKLOG_WAIT_TIME; > /* The identity of the user shutting down the audit system. */ > kuid_t audit_sig_uid = INVALID_UID; > pid_taudit_sig_pid = -1; > -u32 audit_sig_sid = 0; > +u32 audit_sig_sid; All of these are unused outside of audit.c and might as well be static and removed from the .h file.
WARNING in hci_conn_timeout
Hello, syzbot found the following issue on: HEAD commit:7dc6fd0f Merge branch 'i2c/for-current' of git://git.kerne.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12a7083290 kernel config: https://syzkaller.appspot.com/x/.config?x=e59ee776d5aa8d55 dashboard link: https://syzkaller.appspot.com/bug?extid=2446dd3cb07277388db6 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13f781d490 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=116a0c1490 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+2446dd3cb07277388...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 0 PID: 6953 at net/bluetooth/hci_conn.c:412 hci_conn_timeout+0x20f/0x290 net/bluetooth/hci_conn.c:412 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 6953 Comm: kworker/u5:2 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: hci0 hci_conn_timeout Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1f0/0x31e lib/dump_stack.c:118 panic+0x264/0x7a0 kernel/panic.c:231 __warn+0x227/0x250 kernel/panic.c:600 report_bug+0x1b1/0x2e0 lib/bug.c:198 handle_bug+0x42/0x80 arch/x86/kernel/traps.c:235 exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:255 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:540 RIP: 0010:hci_conn_timeout+0x20f/0x290 net/bluetooth/hci_conn.c:412 Code: c7 50 4d 8d 89 e8 71 d0 5f fa 48 8b 35 6a 7c 39 02 bf 40 00 00 00 4c 89 f2 5b 41 5c 41 5e 41 5f e9 46 69 f8 f9 e8 61 c1 20 fa <0f> 0b e9 5c fe ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 1a fe ff RSP: 0018:c90001577cc8 EFLAGS: 00010293 RAX: 8753d0ff RBX: RCX: 888092948440 RDX: RSI: RDI: RBP: 8880a9b7b008 R08: 8753cf3b R09: ed1010da5003 R10: ed1010da5003 R11: R12: 8880a7290d00 R13: 8880a7290d18 R14: 888086d28128 R15: dc00 process_one_work+0x789/0xfc0 kernel/workqueue.c:2269 worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415 kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This report 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 issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
[PATCH] drm/vkms: guarantee vblank when capturing crc
VKMS needs vblank interrupts enabled to capture CRC. When vblank is disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck waiting for a capture that will not occur until vkms wakes up. This patch ensures that vblank remains enabled as long as the CRC capture is needed. It clears the execution of the following kms_cursor_crc subtests: 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding, random, fast-moving])] - successful when running individually. 2. pipe-A-cursor-dpms passes again 3. pipe-A-cursor-suspend also passes The issue was initially tracked in the sequential execution of IGT kms_cursor_crc subtest: when running the test sequence or one of its subtests twice, the odd execs complete and the pairs get stuck in an endless wait. In the IGT code, calling a wait_for_vblank on preparing for CRC capture prevented the busy-wait. But the problem persisted in the pipe-A-cursor-dpms and -suspend subtests. Checking the history, the pipe-A-cursor-dpms subtest was successful when, in vkms_atomic_commit_tail, instead of using the flip_done op, it used wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted blocking in the 2nd start of CRC capture, which may indicate that something got stuck in the step of CRC setup. Indeed, wait_one_vblank in the crc setup was able to sync things and free all kms_cursor_crc subtests. Besides, other alternatives to force enabling vblanks or prevent disabling them such as calling drm_crtc_put_vblank or modeset_enables before commit_planes + offdelay = 0, also unlock all subtests executions. These facts together converge on the lack of vblank to unblock the crc capture. Finally, considering the vkms's dependence on vblank interruptions to perform tasks, this patch acquires a vblank ref when setup CRC source and releases ref when disabling crc capture, ensuring vblanks happen to compute CRC. Cc: Rodrigo Siqueira Cc: Haneen Mohammed Co-developed-by: Sidong Yang Signed-off-by: Sidong Yang Co-developed-by: Daniel Vetter Signed-off-by: Daniel Vetter Signed-off-by: Melissa Wen --- drivers/gpu/drm/vkms/vkms_composer.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 4af2f19480f4..1161eaa383f1 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -241,6 +241,14 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const char *src_name) ret = vkms_crc_parse_source(src_name, &enabled); + /* Ensure that vblank interruptions are enabled for crc capture */ + /* Enabling CRC: acquire vblank ref */ + if (enabled) + drm_crtc_vblank_get(crtc); + /* Disabling CRC: release vblank ref */ + if (!src_name) + drm_crtc_vblank_put(crtc); + spin_lock_irq(&out->lock); out->composer_enabled = enabled; spin_unlock_irq(&out->lock); -- 2.27.0
Re: [PATCH net-next] fib: fix another fib_rules_ops indirect call wrapper problem
From: Brian Vazquez
Date: Fri, 31 Jul 2020 20:01:10 -0700
> It turns out that on commit 41d707b7332f ("fib: fix fib_rules_ops
> indirect calls wrappers") I forgot to include the case when
> CONFIG_IP_MULTIPLE_TABLES is not set.
>
> Fixes: 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers")
> Reported-by: Randy Dunlap
> Cc: Stephen Rothwell
> Signed-off-by: Brian Vazquez
Applied.
[PATCH 2/4] audit: uninitialize global variable audit_sig_sid
Checkpatch tool reports an error at variable audit_sig_sid declaration "ERROR: do not initialise globals to 0" To fix this, the global variable has been uninitialized. Signed-off-by: Jules Irenge --- kernel/audit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/audit.c b/kernel/audit.c index 8c201f414226..7b1a38a211a9 100644 --- a/kernel/audit.c +++ b/kernel/audit.c @@ -125,7 +125,7 @@ static u32 audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME; /* The identity of the user shutting down the audit system. */ kuid_t audit_sig_uid = INVALID_UID; pid_t audit_sig_pid = -1; -u32audit_sig_sid = 0; +u32audit_sig_sid; /* Records can be lost in several ways: 0) [suppressed in audit_alloc] -- 2.26.2
[PATCH 4/4] context_tracking: uninitialize static variables
Checkpatch tool reports an error at a staic variable declaration
"ERROR: do not initialise statics to false"
This is due to the fact that this variable is stored in the buffer
In the .bss section, one can not set an initial value
Here we can trust the compiler to automatically set them to false.
The variable has since been uninitialized.
Signed-off-by: Jules Irenge
---
kernel/context_tracking.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 36a98c48aedc..21881c534152 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -190,7 +190,7 @@ NOKPROBE_SYMBOL(context_tracking_user_exit);
void __init context_tracking_cpu_set(int cpu)
{
- static __initdata bool initialized = false;
+ static __initdata bool initialized;
if (!per_cpu(context_tracking.active, cpu)) {
per_cpu(context_tracking.active, cpu) = true;
--
2.26.2
[PATCH 0/4] Checkpatch tool errors clean up
Hi I am proposing these 4 patches. I am currently learning the core kernel the hard way. I will appreciate any feedback negative or positive. Thanks Jules Irenge (4): acct: Add required space between variable and operator audit: uninitialize global variable audit_sig_sid audit: uninitialize static variables context_tracking: uninitialize static variables kernel/acct.c | 2 +- kernel/audit.c| 10 +- kernel/context_tracking.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.26.2
[PATCH 1/4] acct: Add required space between variable and operator
Checkpatch tool reports an error "ERROR: spaces required around that == (ctx:VxV)" To fix this space has been added between the variable, the operator and the value. Add the missing required space. Signed-off-by: Jules Irenge --- kernel/acct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/acct.c b/kernel/acct.c index b0c5b3a9f5af..d7cc5f917e11 100644 --- a/kernel/acct.c +++ b/kernel/acct.c @@ -451,7 +451,7 @@ static void fill_ac(acct_t *ac) do_div(elapsed, AHZ); btime = ktime_get_real_seconds() - elapsed; ac->ac_btime = clamp_t(time64_t, btime, 0, U32_MAX); -#if ACCT_VERSION==2 +#if ACCT_VERSION == 2 ac->ac_ahz = AHZ; #endif -- 2.26.2
[PATCH 3/4] audit: uninitialize static variables
Checkpatch tool reports an error at variable declaration
"ERROR: do not initialise statics to 0"
This is due to the fact that these variables are stored in the buffer
In the .bss section, one can not set an initial value
Here we can trust the compiler to automatically set them to zero.
The variable has since been uninitialized.
Signed-off-by: Jules Irenge
---
kernel/audit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 7b1a38a211a9..7d79ecb58b01 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -311,8 +311,8 @@ void audit_panic(const char *message)
static inline int audit_rate_check(void)
{
- static unsigned longlast_check = 0;
- static int messages = 0;
+ static unsigned longlast_check;
+ static int messages;
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned long now;
@@ -348,7 +348,7 @@ static inline int audit_rate_check(void)
*/
void audit_log_lost(const char *message)
{
- static unsigned longlast_msg = 0;
+ static unsigned longlast_msg;
static DEFINE_SPINLOCK(lock);
unsigned long flags;
unsigned long now;
@@ -713,7 +713,7 @@ static int kauditd_send_queue(struct sock *sk, u32 portid,
{
int rc = 0;
struct sk_buff *skb;
- static unsigned int failed = 0;
+ static unsigned int failed;
/* NOTE: kauditd_thread takes care of all our locking, we just use
* the netlink info passed to us (e.g. sk and portid) */
--
2.26.2
[PATCH v2] arm64: dts: qcom: sc7180: Add LPASS clock controller nodes
Update the clock controller nodes for Low power audio subsystem
functionality.
Signed-off-by: Taniya Das
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index d46b383..7cf8bfe 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3312,6 +3313,30 @@
qcom,msa-fixed-perm;
status = "disabled";
};
+
+ lpasscc: clock-controller@62d0 {
+ compatible = "qcom,sc7180-lpasscorecc";
+ reg = <0 0x62d0 0 0x5>,
+ <0 0x6278 0 0x3>;
+ reg-names = "lpass_core_cc", "lpass_audio_cc";
+ clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>,
+<&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "bi_tcxo";
+ power-domains = <&lpass_hm LPASS_CORE_HM_GDSCR>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ lpass_hm: clock-controller@6300 {
+ compatible = "qcom,sc7180-lpasshm";
+ reg = <0 0x6300 0 0x28>;
+ clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>,
+<&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "iface", "bi_tcxo";
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
};
thermal-zones {
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH v2] Add LPASS clock controller Node for SC7180
[v2] - Update the node in sorted order. - Depends on the patch https://lore.kernel.org/r/20200731133006.1.Iee81b115f5be50d6d69500fe1bda11bba6e16143@changeid [v1] - Clock controller LPASS device Node. Taniya Das (1): arm64: dts: qcom: sc7180: Add LPASS clock controller nodes arch/arm64/boot/dts/qcom/sc7180.dtsi | 25 + 1 file changed, 25 insertions(+) -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.
Re: [PATCH bpf-next] bpf: make __htab_lookup_and_delete_batch faster when map is almost empty
On Sat, Aug 1, 2020 at 9:59 AM Yonghong Song wrote:
>
>
>
> On 7/31/20 9:57 PM, Brian Vazquez wrote:
> > While running some experiments it was observed that map_lookup_batch was
> > much
> > slower than get_next_key + lookup when the syscall overhead is minimal.
> > This was because the map_lookup_batch implementation was more expensive
> > traversing empty buckets, this can be really costly when the pre-allocated
> > map is too big.
> >
> > This patch optimizes the case when the bucket is empty so we can move
> > quickly
> > to next bucket.
> >
> > The benchmark to exercise this is as follows:
> >
> > -The map was populate with a single entry to make sure that the syscall
> > overhead
> > is not helping the map_batch_lookup.
> > -The size of the preallocated map was increased to show the effect of
> > traversing empty buckets.
> >
> > Results:
> >
> >Using get_next_key + lookup:
> >
> >BenchmarkTime(ns)CPU(ns) Iteration
> >---
> >BM_DumpHashMap/1/1k 3593 3586 192680
> >BM_DumpHashMap/1/4k 6004 5972 10
> >BM_DumpHashMap/1/16k15755 15710 44341
> >BM_DumpHashMap/1/64k59525 59376 1
>
> I think "BM_DumpHashMap/1/64k" means the program "BM_DumpHashMap",
> the map having only "1" entry, and the map preallocated size is "64k"?
> What is the "Iteration" here? The number of runs with the same dump?
> The CPU(ns) is the system cpu consumption, right? The Time/CPU is for
> all iterations, not just one, right? It would be good
> if the above results can be described better, so people can
> understand the results better.
>
Hi Yonghong, thanks for reviewing it!
I'll fix it in next iteration.
> >
> >Using htab_lookup_batch before this patch:
> >BenchmarkTime(ns)CPU(ns) Iterations
> >---
> >BM_DumpHashMap/1/1k 3933 3927 177978
> >BM_DumpHashMap/1/4k 9192 9177 73951
> >BM_DumpHashMap/1/16k42011 41970 16789
> >BM_DumpHashMap/1/64k 117895 117661 6135
> >
> >Using htab_lookup_batch with this patch:
> >BenchmarkTime(ns)CPU(ns) Iterations
> >---
> >BM_DumpHashMap/1/1k 2809 2803 249212
> >BM_DumpHashMap/1/4k 5318 5316 10
> >BM_DumpHashMap/1/16k14925 14895 47448
> >BM_DumpHashMap/1/64k58870 58674 1
> >
> > Suggested-by: Luigi Rizzo
> > Cc: Yonghong Song
> > Signed-off-by: Brian Vazquez
> > ---
> > kernel/bpf/hashtab.c | 23 ---
> > 1 file changed, 8 insertions(+), 15 deletions(-)
> >
> > diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> > index 2137e2200d95..150015ea6737 100644
> > --- a/kernel/bpf/hashtab.c
> > +++ b/kernel/bpf/hashtab.c
> > @@ -1351,7 +1351,6 @@ __htab_map_lookup_and_delete_batch(struct bpf_map
> > *map,
> > struct hlist_nulls_head *head;
> > struct hlist_nulls_node *n;
> > unsigned long flags = 0;
> > - bool locked = false;
> > struct htab_elem *l;
> > struct bucket *b;
> > int ret = 0;
> > @@ -1410,19 +1409,19 @@ __htab_map_lookup_and_delete_batch(struct bpf_map
> > *map,
> > dst_val = values;
> > b = &htab->buckets[batch];
> > head = &b->head;
> > - /* do not grab the lock unless need it (bucket_cnt > 0). */
> > - if (locked)
> > - flags = htab_lock_bucket(htab, b);
> >
> > + l =
> > hlist_nulls_entry_safe(rcu_dereference_raw(hlist_nulls_first_rcu(head)),
> > + struct htab_elem, hash_node);
> > + if (!l && (batch + 1 < htab->n_buckets)) {
> > + batch++;
> > + goto again_nocopy;
> > + }
> > +
> > + flags = htab_lock_bucket(htab, b);
> [...]
Re: xfs_reclaim_inodes_ag taking several seconds
On 01.08.20 12:25, Donald Buczek wrote: So if I understand you correctly, this is expected behavior with this kind of load and conceptual changes are already scheduled for kernel 5.9. I don't understand most of it, but isn't it true that with that planned changes the impact might be better limited to the filesystem, so that the performance of other areas of the system might improve? I'd love to test that with our load, but I don't want to risk our backup data and it would be difficult to produce the same load on a toy system. The patch set is not yet ready to be tested on production data, is it? So I guess I'll try to put the backup processes into one or more cgroups to limit the memory available for their fs caches and leave some room for unrelated (maintenance) processes. I hope, that makes sense. Which it doesn't, because it totally ignores what was said before. The affected processes were not waiting for memory but for the shrinker to finish. D. Thank you both four your analysis! Donald And if you have 30 million inodes in memory, and lots of them are dirty, and the shrinkers are running, then they will be doing dirty inode writeback to throttle memory reclaim to ensure it makes progress and doesn't declare OOM and kill processes permaturely. You have spinning disks, RAID6. I'm betting that it can only clean a couple of hundred inodes a second because RAID6 is severely IOP limited for small writes (like inode clusters). And when you many, many thousands (maybe millions) of dirty inodes, anything that has to wait on inode writeback is going to be waiting for some time... root:done:/home/buczek/linux_problems/shrinker_semaphore/# xfs_info /amd/done/C/C8024 meta-data=/dev/md0 isize=512 agcount=102, agsize=268435328 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=0 data = bsize=4096 blocks=27348629504, imaxpct=1 = sunit=128 swidth=1792 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=521728, version=2 And full size journals, so the filesystem can hold an awful lot of active dirty inodes in memory before it starts throttling on a full journal (think millions of dirty inodes per filesystem)... So, yeah, this is the classic "in memory operation is orders of magnitude faster than disk operation" and it all comes crashing down when something needs to wait for inodes to be written back. The patchset Darrick pointed you at should fix the shrinker issue, but it's likely that this will just push the problem to the next throttling point, which is the journal filling up. IOWs, I suspect fixing your shrinker problem is only going to make the overload of dirty inodes in the system behave worse, because running out of journal space cause *all modifications* to the filesystem to start taking significant delays while they wait for inode writeback to free journal space, not just have things trying to register/unregister shrinkers take delays... Cheers, Dave. -- Donald Buczek buc...@molgen.mpg.de Tel: +49 30 8413 1433
[PATCH V2 bpf-next] bpf: make __htab_lookup_and_delete_batch faster when map is almost empty
While running some experiments it was observed that map_lookup_batch was 2x
slower than get_next_key + lookup when the syscall overhead is minimal.
This was because the map_lookup_batch implementation was more expensive
traversing empty buckets, this can be really costly when the pre-allocated
map is too big.
This patch optimizes the case when the bucket is empty so we can move
quickly to next bucket.
The Benchmark was generated using the google/benchmark library[1]. When
the benckmark is executed the number of iterations is governed by the
amount of time the benckmarks takes, the number of iterations is at
least 1 and not more than 1e9, until CPU time(of the entire binary, not
just the part to measure), is greater than 0.5s. Time and CPU reported
are the average of a single iteration over the iteration runs.
The experiments to exercise the empty buckets are as follows:
-The map was populated with a single entry to make sure that the syscall
overhead is not helping the map_batch_lookup.
-The size of the preallocated map was increased to show the effect of
traversing empty buckets.
To interpret the results, Benchmark is the name of the experiment where
the first number correspond to the number of elements in the map, and
the next one correspond to the size of the pre-allocated map. Time and
CPU are average and correspond to the time elapsed per iteration and the
system time consumtion per iteration.
Results:
Using get_next_key + lookup:
BenchmarkTime(ns)CPU(ns) Iteration
---
BM_DumpHashMap/1/1k 3593 3586 192680
BM_DumpHashMap/1/4k 6004 5972 10
BM_DumpHashMap/1/16k15755 15710 44341
BM_DumpHashMap/1/64k59525 59376 1
Using htab_lookup_batch before this patch:
BenchmarkTime(ns)CPU(ns) Iterations
---
BM_DumpHashMap/1/1k 3933 3927 177978
BM_DumpHashMap/1/4k 9192 9177 73951
BM_DumpHashMap/1/16k42011 41970 16789
BM_DumpHashMap/1/64k 117895 117661 6135
Using htab_lookup_batch with this patch:
BenchmarkTime(ns)CPU(ns) Iterations
---
BM_DumpHashMap/1/1k 2809 2803 249212
BM_DumpHashMap/1/4k 5318 5316 10
BM_DumpHashMap/1/16k14925 14895 47448
BM_DumpHashMap/1/64k58870 58674 1
[1] https://github.com/google/benchmark.git
Changelog:
v1 -> v2:
- Add more information about how to interpret the results
Suggested-by: Luigi Rizzo
Cc: Yonghong Song
Signed-off-by: Brian Vazquez
---
kernel/bpf/hashtab.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 024276787055..b6d28bd6345b 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -1349,7 +1349,6 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
struct hlist_nulls_head *head;
struct hlist_nulls_node *n;
unsigned long flags = 0;
- bool locked = false;
struct htab_elem *l;
struct bucket *b;
int ret = 0;
@@ -1408,19 +1407,19 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
dst_val = values;
b = &htab->buckets[batch];
head = &b->head;
- /* do not grab the lock unless need it (bucket_cnt > 0). */
- if (locked)
- flags = htab_lock_bucket(htab, b);
+ l =
hlist_nulls_entry_safe(rcu_dereference_raw(hlist_nulls_first_rcu(head)),
+ struct htab_elem, hash_node);
+ if (!l && (batch + 1 < htab->n_buckets)) {
+ batch++;
+ goto again_nocopy;
+ }
+
+ flags = htab_lock_bucket(htab, b);
bucket_cnt = 0;
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
bucket_cnt++;
- if (bucket_cnt && !locked) {
- locked = true;
- goto again_nocopy;
- }
-
if (bucket_cnt > (max_count - total)) {
if (total == 0)
ret = -ENOSPC;
@@ -1446,10 +1445,6 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
goto alloc;
}
- /* Next block is only safe to run if you have grabbed the lock */
- if (!locked)
- goto next_batch;
-
hlist_nulls_for_each_entry_safe(l, n, head, hash_node) {
memcpy(dst_key, l->key, key_size);
@@ -1492,7 +1487,6 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
}
htab_unlock_bucket(htab, b, flags);
- locked = f
BUG: stack guard page was hit in arch_stack_walk
Hello, syzbot found the following issue on: HEAD commit:92ed3019 Linux 5.8-rc7 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12c98f2890 kernel config: https://syzkaller.appspot.com/x/.config?x=84f076779e989e69 dashboard link: https://syzkaller.appspot.com/bug?extid=c05e6eff86f7a430fa73 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+c05e6eff86f7a430f...@syzkaller.appspotmail.com BUG: stack guard page was hit at 9157a0b1 (stack is 7cb00dab..55f9d23d) kernel stack overflow (double-fault): [#1] PREEMPT SMP KASAN CPU: 0 PID: 13871 Comm: syz-executor.4 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:arch_stack_walk+0x0/0xf0 arch/x86/kernel/stacktrace.c:17 Code: 8b eb c0 e6 82 89 fa ee ee 8d 57 01 ee ee eb cd e6 81 eb f1 e6 87 eb ed e6 83 eb e9 cc cc cc cc cc cc cc cc cc cc cc cc cc cc <55> 48 89 e5 41 56 49 89 d6 41 55 49 89 cd 41 54 49 89 f4 53 48 89 RSP: 0018:c90008b18000 EFLAGS: 00010246 RAX: RBX: f52001163001 RCX: RDX: 88802b30e480 RSI: c90008b18028 RDI: 8162c090 RBP: 0cc0 R08: ed1006f83078 R09: ed1006f83094 R10: 0001 R11: R12: 0cc0 R13: R14: 88821b77f8c0 R15: 00e0 FS: 7f7369ba8700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c90008b17ff8 CR3: a21ec000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:123 save_stack+0x1b/0x40 mm/kasan/common.c:48 set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494 slab_post_alloc_hook mm/slab.h:586 [inline] slab_alloc_node mm/slab.c:3263 [inline] kmem_cache_alloc_node+0x130/0x3c0 mm/slab.c:3575 __alloc_skb+0x71/0x550 net/core/skbuff.c:198 alloc_skb include/linux/skbuff.h:1083 [inline] nlmsg_new include/net/netlink.h:940 [inline] rtmsg_ifinfo_build_skb+0x72/0x1a0 net/core/rtnetlink.c:3702 rtmsg_ifinfo_event net/core/rtnetlink.c:3738 [inline] rtmsg_ifinfo_event net/core/rtnetlink.c:3729 [inline] rtnetlink_event+0x123/0x1d0 net/core/rtnetlink.c:5512 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2027 call_netdevice_notifiers_extack net/core/dev.c:2039 [inline] call_netdevice_notifiers net/core/dev.c:2053 [inline] netdev_features_change net/core/dev.c:1443 [inline] netdev_sync_lower_features net/core/dev.c:9056 [inline] __netdev_update_features+0x88d/0x1360 net/core/dev.c:9187 netdev_change_features+0x61/0xb0 net/core/dev.c:9259 bond_compute_features+0x502/0xa00 drivers/net/bonding/bond_main.c:1188 bond_slave_netdev_event drivers/net/bonding/bond_main.c:3237 [inline] bond_netdev_event+0x81f/0xb30 drivers/net/bonding/bond_main.c:3277 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2027 call_netdevice_notifiers_extack net/core/dev.c:2039 [inline] call_netdevice_notifiers net/core/dev.c:2053 [inline] netdev_features_change net/core/dev.c:1443 [inline] netdev_sync_lower_features net/core/dev.c:9056 [inline] __netdev_update_features+0x88d/0x1360 net/core/dev.c:9187 netdev_change_features+0x61/0xb0 net/core/dev.c:9259 bond_compute_features+0x502/0xa00 drivers/net/bonding/bond_main.c:1188 bond_slave_netdev_event drivers/net/bonding/bond_main.c:3237 [inline] bond_netdev_event+0x81f/0xb30 drivers/net/bonding/bond_main.c:3277 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2027 call_netdevice_notifiers_extack net/core/dev.c:2039 [inline] call_netdevice_notifiers net/core/dev.c:2053 [inline] netdev_features_change net/core/dev.c:1443 [inline] netdev_sync_lower_features net/core/dev.c:9056 [inline] __netdev_update_features+0x88d/0x1360 net/core/dev.c:9187 netdev_change_features+0x61/0xb0 net/core/dev.c:9259 bond_compute_features+0x502/0xa00 drivers/net/bonding/bond_main.c:1188 bond_slave_netdev_event drivers/net/bonding/bond_main.c:3237 [inline] bond_netdev_event+0x81f/0xb30 drivers/net/bonding/bond_main.c:3277 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2027 call_netdevice_notifiers_extack net/core/dev.c:2039 [inline] call_netdevice_notifiers net/core/dev.c:2053 [inline] netdev_features_change net/core/dev.c:1443 [inline] netdev_sync_lower_features net/core/dev.c:9056 [inline] __netdev_update_features+0x88d/0x1360 net/core/dev.c:9187 n
Re: [PATCH] platform_data: ad7793.h: drop a duplicated word
On Sat, 18 Jul 2020 17:30:40 -0700
Randy Dunlap wrote:
> Drop the repeated word "and" in a comment.
>
> Signed-off-by: Randy Dunlap
> Cc: Lars-Peter Clausen
> Cc: Jonathan Cameron
Applied to the togreg branch of iio.git
Thanks,
Jonathan
> ---
> include/linux/platform_data/ad7793.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20200717.orig/include/linux/platform_data/ad7793.h
> +++ linux-next-20200717/include/linux/platform_data/ad7793.h
> @@ -40,7 +40,7 @@ enum ad7793_bias_voltage {
> * enum ad7793_refsel - AD7793 reference voltage selection
> * @AD7793_REFSEL_REFIN1: External reference applied between REFIN1(+)
> * and REFIN1(-).
> - * @AD7793_REFSEL_REFIN2: External reference applied between REFIN2(+) and
> + * @AD7793_REFSEL_REFIN2: External reference applied between REFIN2(+)
> * and REFIN1(-). Only valid for AD7795/AD7796.
> * @AD7793_REFSEL_INTERNAL: Internal 1.17 V reference.
> */
[PATCH v3] staging: r8188eu: replace rtw_netdev_priv define with inline function
The function guarantees type checking of arguments and return value.
Result of rtw_netdev_priv macro can be assigned to pointer
with incompatible type without warning. The function allow compiler
to perform this check.
Signed-off-by: Ivan Safonov
---
Changes in v2:
- add blank line after function definition;
- improve commit message.
Changes in v3:
- use proper argument name;
- remove unnecessary parentheses.
---
drivers/staging/rtl8188eu/include/osdep_service.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h
b/drivers/staging/rtl8188eu/include/osdep_service.h
index 31d897f1d21f..b44d602e954a 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -71,8 +71,11 @@ struct rtw_netdev_priv_indicator {
};
struct net_device *rtw_alloc_etherdev_with_old_priv(void *old_priv);
-#define rtw_netdev_priv(netdev)\
- (((struct rtw_netdev_priv_indicator *)netdev_priv(netdev))->priv)
+static inline struct adapter *rtw_netdev_priv(struct net_device *netdev)
+{
+ return ((struct rtw_netdev_priv_indicator *)netdev_priv(netdev))->priv;
+}
+
void rtw_free_netdev(struct net_device *netdev);
#define FUNC_NDEV_FMT "%s(%s)"
--
2.26.2
Re: [PATCH 1/2] habanalabs: Replace dma-fence mechanism with completions
Hi Oded, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on char-misc/char-misc-testing] [cannot apply to linux/master linus/master v5.8-rc7] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Oded-Gabbay/habanalabs-Replace-dma-fence-mechanism-with-completions/20200730-211536 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 22362aa30bad6f03b5bcbbeee3cdc61950d40086 config: x86_64-randconfig-s022-20200801 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-115-g5fc204f2-dirty # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/misc/habanalabs/common/command_submission.c:41:6: sparse: sparse: >> symbol 'hl_fence_release' was not declared. Should it be static? >> drivers/misc/habanalabs/common/command_submission.c:101:6: sparse: sparse: >> symbol 'hl_fence_init' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[RFC PATCH] habanalabs: hl_fence_release() can be static
Signed-off-by: kernel test robot
---
command_submission.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/habanalabs/common/command_submission.c
b/drivers/misc/habanalabs/common/command_submission.c
index d19ac641b1719..e482d8d135602 100644
--- a/drivers/misc/habanalabs/common/command_submission.c
+++ b/drivers/misc/habanalabs/common/command_submission.c
@@ -38,7 +38,7 @@ void hl_sob_reset_error(struct kref *ref)
hw_sob->q_idx, hw_sob->sob_id);
}
-void hl_fence_release(struct kref *kref)
+static void hl_fence_release(struct kref *kref)
{
struct hl_fence *fence =
container_of(kref, struct hl_fence, refcount);
@@ -98,7 +98,7 @@ void hl_fence_get(struct hl_fence *fence)
kref_get(&fence->refcount);
}
-void hl_fence_init(struct hl_fence *fence)
+static void hl_fence_init(struct hl_fence *fence)
{
kref_init(&fence->refcount);
fence->error = 0;
[PATCH] arm64: dts: rockchip: add SPDIF node for rk3399-rockpro64
This patch adds 'disabled' SPDIF sound node and related settings
for rk3399-rockpro64.
There are 2 reasons:
- All RK3399 dma-bus channels have been already used by I2S0/1/2
- RockPro64 does not have SPDIF optical nor coaxial connector,
just have 3pins
Signed-off-by: Katsuhiro Suzuki
---
.../boot/dts/rockchip/rk3399-rockpro64.dtsi | 28 +++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index 6e553ff47534..e35b30f8a46e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -76,6 +76,23 @@ sound {
dais = <&i2s1_p0>;
};
+ sound-dit {
+ compatible = "audio-graph-card";
+ label = "rockchip,rk3399";
+ dais = <&spdif_p0>;
+ };
+
+ spdif-dit {
+ compatible = "linux,spdif-dit";
+ #sound-dai-cells = <0>;
+
+ port {
+ dit_p0_0: endpoint {
+ remote-endpoint = <&spdif_p0_0>;
+ };
+ };
+ };
+
vcc12v_dcin: vcc12v-dcin {
compatible = "regulator-fixed";
regulator-name = "vcc12v_dcin";
@@ -698,6 +715,17 @@ &sdhci {
status = "okay";
};
+&spdif {
+ pinctrl-0 = <&spdif_bus_1>;
+ status = "disabled";
+
+ spdif_p0: port {
+ spdif_p0_0: endpoint {
+ remote-endpoint = <&dit_p0_0>;
+ };
+ };
+};
+
&spi1 {
status = "okay";
--
2.27.0
Re: [PATCH 0/6] perf tools: Add wallclock time conversion support
Em Fri, Jul 31, 2020 at 06:46:21PM -0600, David Ahern escreveu: > On 7/31/20 12:05 PM, pet...@infradead.org wrote: > > On Fri, Jul 31, 2020 at 08:36:12AM -0700, Andi Kleen wrote: > >>> yep, we have a customer that needs to compare data from multiple servers > >> It's also needed to correlate over different guests on the same machine. > >> This is an important use case. > > Both these cases you want to sync up CLOCK_MONOTONIC, using walltime is > > just utterly misguided. > Every userspace component logs in walltime. You can say that is > misguided, but that is the way it is. The missing piece is the ability > to correlate kernel events to userspace logs. > > What happens if the servers have (per accident or otherwise) different > > DST settings, or someone does a clock_setttime() for giggles. > Yes, someone *could* change the time. Someone *could* start ntpd or > other time server in the middle of a session. While technically such > things can happen, that is not real life in most environments (e.g., > Data center servers). ntpd (or other) is started at boot, and it is just > the little misc adjustments that happen over time. > We could add tracepoints and detect the changes and invalidate the > reference time. We could add tracepoints to track the adjustments and > update the reference time. In my experience over 9+ years using this > tool (out of tree patches) that has never been the problem. > > All you really want is a clock that runs at the same rate but is not > > subject to random jumps and user foibles. > All I want is to compare user logs to a kernel event via timestamps. Can we have both possibilities and leave the decision on which one to use in the hands of those who have a gun to shoot wherever they want, maybe in the foot? - Arnaldo
Re: [PATCH] splice: direct call for default_file_splice*()
On Sat, Aug 01, 2020 at 01:12:22PM +0300, Pavel Begunkov wrote:
> On 30/01/2020 19:54, Christoph Hellwig wrote:
> > On Mon, Jan 20, 2020 at 11:49:46PM +0300, Pavel Begunkov wrote:
> >> Indirect calls could be very expensive nowadays, so try to use direct calls
> >> whenever possible.
>
> Hah, I'm surprised to find it as
> 00c285d0d0fe4 ("fs: simplify do_splice_from").
>
> Christoph, even though this one is not a big deal, I'm finding the
> practice of taking others patches and silently sending them as yours
> own in general disgusting. Just for you to know.
Err, what makes you think I took your patch vs just not remembering
and pointlessly doing the same cleanup again? If I had rembered your
patch I would have just added to the series with your credit as I've
done for plenty other patches..
Re: [PATCH v9 09/12] PCI: brcmstb: Set additional internal memory DMA viewport sizes
Hi Jim,
On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> The Raspberry Pi (RPI) is currently the only chip using this driver
> (pcie-brcmstb.c). There, only one memory controller is used, without an
> extension region, and the SCB0 viewport size is set to the size of the
> first and only dma-range region. Other BrcmSTB SOCs have more complicated
> memory configurations that require setting additional viewport sizes.
>
> BrcmSTB PCIe controllers are intimately connected to the memory
> controller(s) on the SOC. The SOC may have one to three memory
> controllers; they are indicated by the term SCBi. Each controller has a
> base region and an optional extension region. In physical memory, the base
> and extension regions of a controller are not adjacent, but in PCIe-space
> they are.
>
> There is a "viewport" for each memory controller that allows DMA from
> endpoint devices. Each viewport's size must be set to a power of two, and
> that size must be equal to or larger than the amount of memory each
> controller supports which is the sum of base region and its optional
> extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
>
> Unfortunately the viewport sizes cannot be ascertained from the
> "dma-ranges" property so they have their own property, "brcm,scb-sizes".
> This is because dma-range information does not indicate what memory
> controller it is associated. For example, consider the following case
> where the size of one dma-range is 2GB and the second dma-range is 1GB:
>
> /* Case 1: SCB0 size set to 4GB */
> dma-range0: 2GB (from memc0-base)
> dma-range1: 1GB (from memc0-extension)
>
> /* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
> dma-range0: 2GB (from memc0-base)
> dma-range1: 1GB (from memc0-extension)
>
> By just looking at the dma-ranges information, one cannot tell which
> situation applies. That is why an additional property is needed. Its
> length indicates the number of memory controllers being used and each value
> indicates the viewport size.
>
> Note that the RPI DT does not have a "brcm,scb-sizes" property value,
> as it is assumed that it only requires one memory controller and no
> extension. So the optional use of "brcm,scb-sizes" will be backwards
> compatible.
>
> One last layer of complexity exists: all of the viewports sizes must be
> added and rounded up to a power of two to determine what the "BAR" size is.
> Further, an offset must be given that indicates the base PCIe address of
> this "BAR". The use of the term BAR is typically associated with endpoint
> devices, and the term is used here because the PCIe HW may be used as an RC
> or an EP. In the former case, all of the system memory appears in a single
> "BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
> used in the EP role and its system of mapping memory is an artifact that
> requires multiple dma-ranges regions.
>
> Signed-off-by: Jim Quinlan
> Acked-by: Florian Fainelli
> ---
> drivers/pci/controller/pcie-brcmstb.c | 68 ---
> 1 file changed, 50 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-brcmstb.c
> index 8dacb9d3b7b6..3ef2d37cc43b 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -715,22 +720,44 @@ static inline int
> brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
> u64 *rc_bar2_offset)
> {
> struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> - struct device *dev = pcie->dev;
> struct resource_entry *entry;
> + struct device *dev = pcie->dev;
> + u64 lowest_pcie_addr = ~(u64)0;
> + int ret, i = 0;
> + u64 size = 0;
>
> - entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
> - if (!entry)
> - return -ENODEV;
> + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
> + u64 pcie_beg = entry->res->start - entry->offset;
>
> + size += entry->res->end - entry->res->start + 1;
> + if (pcie_beg < lowest_pcie_addr)
> + lowest_pcie_addr = pcie_beg;
> + }
>
> - /*
> - * The controller expects the inbound window offset to be calculated as
> - * the difference between PCIe's address space and CPU's. The offset
> - * provided by the firmware is calculated the opposite way, so we
> - * negate it.
> - */
> - *rc_bar2_offset = -entry->offset;
> - *rc_bar2_size = 1ULL << fls64(entry->res->end - entry->res->start);
> + if (lowest_pcie_addr == ~(u64)0) {
> + dev_err(dev, "DT node has no dma-ranges\n");
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_variable_u64_array(pcie->np, "brcm,scb-sizes",
> pcie->memc_size, 1,
> + PC
Re: INFO: task hung in pipe_read (2)
On Sat, Aug 1, 2020 at 8:30 AM Tetsuo Handa wrote: > > Waiting for response at > https://lkml.kernel.org/r/45a9b2c8-d0b7-8f00-5b30-0cfe3e028...@i-love.sakura.ne.jp > . I think handle_userfault() should have a (shortish) timeout, and just return VM_FAULT_RETRY. The code is overly complex anyway, because it predates the "just return RETRY". And because we can't wait forever when the source of the fault is a kernel exception, I think we should add some extra logic to just say "if this is a retry, we've already done this once, just return an error". This is a TEST PATCH ONLY. I think we'll actually have to do something like this, but I think the final version might need to allow a couple of retries, rather than just give up after just one second. But for testing your case, this patch might be enough to at least show that "yeah, this kind of approach works". Andrea? Comments? As mentioned, this is probably much too aggressive, but I do think we need to limit the time that the kernel will wait for page faults. Because userfaultfd has become a huge source of security holes as a way to time kernel faults or delay them indefinitely. Linus patch Description: Binary data
[PATCH v8 1/2] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()
In reaction to a proposal to introduce a memcpy_mcsafe_fast()
implementation Linus points out that memcpy_mcsafe() is poorly named
relative to communicating the scope of the interface. Specifically what
addresses are valid to pass as source, destination, and what faults /
exceptions are handled. Of particular concern is that even though x86
might be able to handle the semantics of copy_mc_to_user() with its
common copy_user_generic() implementation other archs likely need / want
an explicit path for this case:
On Fri, May 1, 2020 at 11:28 AM Linus Torvalds
wrote:
>
> On Thu, Apr 30, 2020 at 6:21 PM Dan Williams
wrote:
> >
> > However now I see that copy_user_generic() works for the wrong reason.
> > It works because the exception on the source address due to poison
> > looks no different than a write fault on the user address to the
> > caller, it's still just a short copy. So it makes copy_to_user() work
> > for the wrong reason relative to the name.
>
> Right.
>
> And it won't work that way on other architectures. On x86, we have a
> generic function that can take faults on either side, and we use it
> for both cases (and for the "in_user" case too), but that's an
> artifact of the architecture oddity.
>
> In fact, it's probably wrong even on x86 - because it can hide bugs -
> but writing those things is painful enough that everybody prefers
> having just one function.
The rename replaces a single top-level memcpy_mcsafe() with either
copy_mc_to_user(), or copy_mc_to_kernel().
An x86 copy_mc_fragile() name is introduced as the rename for the
low-level x86 implementation formerly named memcpy_mcsafe(). It is used
as the slow / careful backend that is supplanted by a fast
copy_mc_generic() in a follow-on patch.
One side-effect of this reorganization is that separating copy_mc_64.S
to its own file means that perf no longer needs to track dependencies
for its memcpy_64.S benchmarks.
Cc: x...@kernel.org
Cc:
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Paul Mackerras
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Mikulas Patocka
Cc: Alexander Viro
Cc: Arnaldo Carvalho de Melo
Cc: Linus Torvalds
Cc: Benjamin Herrenschmidt
Reviewed-by: Tony Luck
Acked-by: Michael Ellerman
Link:
http://lore.kernel.org/r/CAHk-=wjsqtxaqfujxftwnwmgufastgb0dz1dt3v-78quiez...@mail.gmail.com
Signed-off-by: Dan Williams
---
arch/powerpc/Kconfig |2
arch/powerpc/include/asm/string.h |2
arch/powerpc/include/asm/uaccess.h | 40 --
arch/powerpc/lib/Makefile |2
arch/powerpc/lib/copy_mc_64.S |4 -
arch/x86/Kconfig |2
arch/x86/Kconfig.debug |2
arch/x86/include/asm/copy_mc_test.h| 75
arch/x86/include/asm/mcsafe_test.h | 75
arch/x86/include/asm/string_64.h | 32 -
arch/x86/include/asm/uaccess.h | 18 +++
arch/x86/include/asm/uaccess_64.h | 20 ---
arch/x86/kernel/cpu/mce/core.c |8 -
arch/x86/kernel/quirks.c |9 -
arch/x86/lib/Makefile |1
arch/x86/lib/copy_mc.c | 66 +++
arch/x86/lib/copy_mc_64.S | 125
arch/x86/lib/memcpy_64.S | 115 --
arch/x86/lib/usercopy_64.c | 21 ---
drivers/md/dm-writecache.c | 15 +-
drivers/nvdimm/claim.c |2
drivers/nvdimm/pmem.c |6 -
include/linux/string.h |9 -
include/linux/uaccess.h|9 +
include/linux/uio.h| 10 +-
lib/Kconfig|7 +
lib/iov_iter.c | 43 ---
tools/arch/x86/include/asm/mcsafe_test.h | 13 --
tools/arch/x86/lib/memcpy_64.S | 115 --
tools/objtool/check.c |4 -
tools/perf/bench/Build |1
tools/perf/bench/mem-memcpy-x86-64-lib.c | 24
tools/testing/nvdimm/test/nfit.c | 48
.../testing/selftests/powerpc/copyloops/.gitignore |2
tools/testing/selftests/powerpc/copyloops/Makefile |6 -
.../selftests/powerpc/copyloops/copy_mc_64.S |1
.../selftests/powerpc/copyloops/memcpy_mcsafe_64.S |1
37 files changed, 409 insertions(+), 526 deletions(-)
rename arch/powerpc/lib/{memcpy_mcsafe_64.S => copy_mc_64.S} (98%)
create mode 100644 arch/x86/include/asm/copy_mc_test.h
delete mode 100644 arch/x86/include/asm/mc
[PATCH v8 2/2] x86/copy_mc: Introduce copy_mc_generic()
The original copy_mc_fragile() implementation had negative performance
implications since it did not use the fast-string instruction sequence
to perform copies. For this reason copy_mc_to_kernel() fell back to
plain memcpy() to preserve performance on platform that did not indicate
the capability to recover from machine check exceptions. However, that
capability detection was not architectural and now that some platforms
can recover from fast-string consumption of memory errors the memcpy()
fallback now causes these more capable platforms to fail.
Introduce copy_mc_generic() as the fast default implementation of
copy_mc_to_kernel() and finalize the transition of copy_mc_fragile() to
be a platform quirk to indicate 'fragility'. With this in place
copy_mc_to_kernel() is fast and recovery-ready by default regardless of
hardware capability.
Thanks to Vivek for identifying that copy_user_generic() is not suitable
as the copy_mc_to_user() backend since the #MC handler explicitly checks
ex_has_fault_handler().
Cc: x...@kernel.org
Cc:
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Vivek Goyal
Cc: "H. Peter Anvin"
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Linus Torvalds
Reviewed-by: Tony Luck
Reported-by: Erwin Tsaur
Tested-by: Erwin Tsaur
Fixes: 92b0729c34ca ("x86/mm, x86/mce: Add memcpy_mcsafe()")
Signed-off-by: Dan Williams
---
arch/x86/include/asm/uaccess.h |3 +++
arch/x86/lib/copy_mc.c | 12 +---
arch/x86/lib/copy_mc_64.S | 40
tools/objtool/check.c |1 +
4 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 4b2082b61e3e..b038eda58958 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -464,6 +464,9 @@ copy_mc_to_user(void *to, const void *from, unsigned len);
unsigned long __must_check
copy_mc_fragile(void *dst, const void *src, unsigned cnt);
+
+unsigned long __must_check
+copy_mc_generic(void *dst, const void *src, unsigned cnt);
#else
static inline void enable_copy_mc_fragile(void)
{
diff --git a/arch/x86/lib/copy_mc.c b/arch/x86/lib/copy_mc.c
index cdb8f5dc403d..9e6fac1ab72e 100644
--- a/arch/x86/lib/copy_mc.c
+++ b/arch/x86/lib/copy_mc.c
@@ -23,7 +23,7 @@ void enable_copy_mc_fragile(void)
*
* Call into the 'fragile' version on systems that have trouble
* actually do machine check recovery. Everyone else can just
- * use memcpy().
+ * use copy_mc_generic().
*
* Return 0 for success, or number of bytes not copied if there was an
* exception.
@@ -33,8 +33,7 @@ copy_mc_to_kernel(void *dst, const void *src, unsigned cnt)
{
if (static_branch_unlikely(©_mc_fragile_key))
return copy_mc_fragile(dst, src, cnt);
- memcpy(dst, src, cnt);
- return 0;
+ return copy_mc_generic(dst, src, cnt);
}
EXPORT_SYMBOL_GPL(copy_mc_to_kernel);
@@ -56,11 +55,10 @@ copy_mc_to_user(void *to, const void *from, unsigned len)
{
unsigned long ret;
- if (!static_branch_unlikely(©_mc_fragile_key))
- return copy_user_generic(to, from, len);
-
__uaccess_begin();
- ret = copy_mc_fragile(to, from, len);
+ if (static_branch_unlikely(©_mc_fragile_key))
+ ret = copy_mc_fragile(to, from, len);
+ ret = copy_mc_generic(to, from, len);
__uaccess_end();
return ret;
}
diff --git a/arch/x86/lib/copy_mc_64.S b/arch/x86/lib/copy_mc_64.S
index 35a67c50890b..a08e7a4d9e28 100644
--- a/arch/x86/lib/copy_mc_64.S
+++ b/arch/x86/lib/copy_mc_64.S
@@ -2,7 +2,9 @@
/* Copyright(c) 2016-2020 Intel Corporation. All rights reserved. */
#include
+#include
#include
+#include
#include
#include
@@ -122,4 +124,42 @@ EXPORT_SYMBOL_GPL(copy_mc_fragile)
_ASM_EXTABLE(.L_write_leading_bytes, .E_leading_bytes)
_ASM_EXTABLE(.L_write_words, .E_write_words)
_ASM_EXTABLE(.L_write_trailing_bytes, .E_trailing_bytes)
+
+/*
+ * copy_mc_generic - memory copy with exception handling
+ *
+ * Fast string copy + fault / exception handling. If the CPU does
+ * support machine check exception recovery, but does not support
+ * recovering from fast-string exceptions then this CPU needs to be
+ * added to the copy_mc_fragile_key set of quirks. Otherwise, absent any
+ * machine check recovery support this version should be no slower than
+ * standard memcpy.
+ */
+SYM_FUNC_START(copy_mc_generic)
+ ALTERNATIVE "jmp copy_mc_fragile", "", X86_FEATURE_ERMS
+ movq %rdi, %rax
+ movq %rdx, %rcx
+.L_copy:
+ rep movsb
+ /* Copy successful. Return zero */
+ xorl %eax, %eax
+ ret
+SYM_FUNC_END(copy_mc_generic)
+EXPORT_SYMBOL_GPL(copy_mc_generic)
+
+ .section .fixup, "ax"
+.E_copy:
+ /*
+* On fault %rcx is updated such that the copy instruction could
+* optionally be restarted at the fault position, i.e. it
+* contains '
[PATCH v8 0/2] Renovate memcpy_mcsafe with copy_mc_to_{user, kernel}
Changes since v7 [1]:
- Rebased on v5.8-rc5 to resolve a conflict with commit eb25de276505
("tools arch: Update arch/x86/lib/memcpy_64.S copy used in 'perf bench
mem memcpy'")
[1]:
http://lore.kernel.org/r/159408043801.2272533.17485467640602344900.st...@dwillia2-desk3.amr.corp.intel.com
---
Vishal, since this patch set has experienced unprecedented silence from
x86 folks I expect you will need to send it to Linus directly during the
merge window. It merges cleanly with recent -next.
Thomas, Ingo, Boris, please chime in to save Vishal from that
awkwardness. I am only going to be sporadically online for the next few
weeks.
---
The primary motivation to go touch memcpy_mcsafe() is that the existing
benefit of doing slow and careful copies is obviated on newer CPUs. That
fact solves the problem of needing to detect machine-check recovery
capability. Now the old "mcsafe_key" opt-in to careful copying can be made
an opt-out from the default fast copy implementation.
The discussion with Linus further made clear that this facility had
already lost its x86-machine-check specificity starting with commit
2c89130a56a ("x86/asm/memcpy_mcsafe: Add write-protection-fault
handling"). The new changes to not require a "careful copy" further
de-emphasizes the role that x86-MCA plays in the implementation to just
one more source of recoverable trap during the operation.
With the above realizations the name "mcsafe" is no longer accurate and
copy_safe() is proposed as its replacement. x86 grows a copy_safe_fast()
implementation as a default implementation that is independent of
detecting the presence of x86-MCA.
---
Dan Williams (2):
x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user,kernel}()
x86/copy_mc: Introduce copy_mc_generic()
arch/powerpc/Kconfig |2
arch/powerpc/include/asm/string.h |2
arch/powerpc/include/asm/uaccess.h | 40 +++--
arch/powerpc/lib/Makefile |2
arch/powerpc/lib/copy_mc_64.S |4
arch/x86/Kconfig |2
arch/x86/Kconfig.debug |2
arch/x86/include/asm/copy_mc_test.h| 75 +
arch/x86/include/asm/mcsafe_test.h | 75 -
arch/x86/include/asm/string_64.h | 32
arch/x86/include/asm/uaccess.h | 21 +++
arch/x86/include/asm/uaccess_64.h | 20 --
arch/x86/kernel/cpu/mce/core.c |8 -
arch/x86/kernel/quirks.c |9 -
arch/x86/lib/Makefile |1
arch/x86/lib/copy_mc.c | 64
arch/x86/lib/copy_mc_64.S | 165
arch/x86/lib/memcpy_64.S | 115 --
arch/x86/lib/usercopy_64.c | 21 ---
drivers/md/dm-writecache.c | 15 +-
drivers/nvdimm/claim.c |2
drivers/nvdimm/pmem.c |6 -
include/linux/string.h |9 -
include/linux/uaccess.h|9 +
include/linux/uio.h| 10 +
lib/Kconfig|7 +
lib/iov_iter.c | 43 +++--
tools/arch/x86/include/asm/mcsafe_test.h | 13 --
tools/arch/x86/lib/memcpy_64.S | 115 --
tools/objtool/check.c |5 -
tools/perf/bench/Build |1
tools/perf/bench/mem-memcpy-x86-64-lib.c | 24 ---
tools/testing/nvdimm/test/nfit.c | 48 +++---
.../testing/selftests/powerpc/copyloops/.gitignore |2
tools/testing/selftests/powerpc/copyloops/Makefile |6 -
.../selftests/powerpc/copyloops/copy_mc_64.S |1
.../selftests/powerpc/copyloops/memcpy_mcsafe_64.S |1
37 files changed, 451 insertions(+), 526 deletions(-)
rename arch/powerpc/lib/{memcpy_mcsafe_64.S => copy_mc_64.S} (98%)
create mode 100644 arch/x86/include/asm/copy_mc_test.h
delete mode 100644 arch/x86/include/asm/mcsafe_test.h
create mode 100644 arch/x86/lib/copy_mc.c
create mode 100644 arch/x86/lib/copy_mc_64.S
delete mode 100644 tools/arch/x86/include/asm/mcsafe_test.h
delete mode 100644 tools/perf/bench/mem-memcpy-x86-64-lib.c
create mode 12 tools/testing/selftests/powerpc/copyloops/copy_mc_64.S
delete mode 12 tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S
base-commit: 11ba468877bb23f28956a35e896356252d63c983
Re: [PATCH v2] staging: r8188eu: replace rtw_netdev_priv define with inline function
On Sat, 2020-08-01 at 19:52 +0300, Ivan Safonov wrote:
> The function guarantees type checking of arguments and return value.
>
> Result of rtw_netdev_priv macro can be assigned to pointer
> with incompatible type without warning. The function allow compiler
> to perform this check.
[]
> diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h
> b/drivers/staging/rtl8188eu/include/osdep_service.h
[]
> @@ -71,8 +71,11 @@ struct rtw_netdev_priv_indicator {
> };
> struct net_device *rtw_alloc_etherdev_with_old_priv(void *old_priv);
>
> -#define rtw_netdev_priv(netdev) \
> - (((struct rtw_netdev_priv_indicator *)netdev_priv(netdev))->priv)
> +static inline struct adapter *rtw_netdev_priv(struct net_device *dev)
> +{
> + return (((struct rtw_netdev_priv_indicator *)netdev_priv(dev))->priv);
> +}
To be similar to existing uses, this variable name should be
netdev not dev. There are also unnecessary parentheses.
> void rtw_free_netdev(struct net_device *netdev);
Better to use netdev like this one.
---
static inline struct adapter *rtw_netdev_priv(struct net_device *netdev)
{
return ((struct rtw_netdev_priv_indicator *)netdev_priv(netdev))->priv;
}
