April 2021 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Re: [kernel]:overlayfs: invalid origin (root/bmcweb_persistent_data.json, ftype=8000, origin ftype=4000)
by Amir Goldstein April 27, 2021

April 27, 2021

On Thu, Apr 15, 2021 at 2:03 PM www <ouyangxuan10(a)163.com> wrote: > > Dear Amir, kevin, miklos, > > An open source project uses overlay filesystem and systemd. when the system first time boot, there is an error in the file system: > kernel: overlayfs: invalid origin (root/bmcweb_persistent_data.json, ftype=8000, origin ftype=4000) > > What's the reason for this? Can you give some help and suggestions to solve this problem? > > The details are as follows: > 1. linux kernel version: > root@N/A:~# uname -a Linux N/A 5.1.5-yocto-s-dirty-1605363 #1 Tue Apr 13 01:13:48 UTC 2021 armv6l GNU/Linux > > 2. mount command > mount -t overlay -o lowerdir=$rodir,upperdir=$upper,workdir=$work cow /root > (rodir=run/initramfs/ro, upper=run/initramfs/rw/cow, work=rwdir=run/initramfs/rw/work) > > 3. mountinfo > root@N/A:~# cat /proc/self/mountinfo > 13 21 0:6 / /dev rw,relatime shared:8 - devtmpfs dev rw,size=220800k,nr_inodes=55200,mode=755 > 14 21 0:13 / /sys rw,relatime shared:3 - sysfs sys rw > 15 21 0:4 / /proc rw,relatime shared:2 - proc proc rw > 16 21 0:14 / /run rw,nosuid,nodev shared:11 - tmpfs tmpfs rw,mode=755 > 17 16 7:0 / /run/initramfs/ro ro,relatime shared:12 - squashfs /dev/loop0 ro > 18 16 31:5 / /run/initramfs/rw rw,relatime shared:13 - jffs2 /dev/mtdblock5 rw > 21 0 0:15 / / rw,relatime shared:1 - overlay cow rw,lowerdir=run/initramfs/ro,upperdir=run/initramfs/rw/cow,workdir=run/initramfs/rw/work > 22 13 0:17 / /dev/shm rw,nosuid,nodev shared:9 - tmpfs tmpfs rw > 23 13 0:18 / /dev/pts rw,relatime shared:10 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 > 24 14 0:19 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:4 - tmpfs tmpfs ro,mode=755 > 25 24 0:20 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:5 - cgroup2 cgroup2 rw,nsdelegate > 26 24 0:21 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:6 - cgroup cgroup rw,xattr,name=systemd > 27 14 0:22 / /sys/fs/bpf rw,nosuid,nodev,noexec,relatime shared:7 - bpf bpf rw,mode=700 > 28 14 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime shared:14 - debugfs debugfs rw > 29 14 0:12 / /sys/kernel/config rw,nosuid,nodev,noexec,relatime shared:15 - configfs configfs rw > 30 21 0:23 / /tmp rw,nosuid,nodev shared:16 - tmpfs tmpfs rw > 31 21 0:24 / /var/volatile rw,relatime shared:17 - tmpfs tmpfs rw > > 4. xino_auto > > 5. file in ro is correct > 6. file in rw is correct > 7. but the file in overlayfs is incorrect > > What's the reason for this? I suppose lower squashfs was recreated and mounted with an existing upper dir that already contains upper files with origin references to the old squashfs lower fs. > Can you give some help and suggestions to solve this problem? Cherry-pick this fix to your kernel: a888db310195 ovl: fix regression with re-formatted lower squashfs OR as a workaround, build the lower squashfs with the "-no-exports" mksquashfs option. Thanks, Amir.

2 3

Re: [PATCH] drivers: pnp: proc.c: Removed unnecessary varibles
by Leon Romanovsky April 27, 2021

April 27, 2021

On Mon, Apr 26, 2021 at 11:22:54PM +0530, bkkarthik wrote: > On 21/04/26 03:50PM, Leon Romanovsky wrote: > > On Mon, Apr 26, 2021 at 02:00:58PM +0200, Rafael J. Wysocki wrote: > > > On Mon, Apr 26, 2021 at 6:57 AM Leon Romanovsky <leon(a)kernel.org> wrote: > > > > > > > > On Fri, Apr 23, 2021 at 03:08:03PM -0600, Shuah Khan wrote: > > > > > On 4/22/21 12:03 PM, Anupama K Patil wrote: > > > > > > de, e are two variables of the type 'struct proc_dir_entry' > > > > > > which can be removed to save memory. This also fixes a coding style > > > > > > issue reported by checkpatch where we are suggested to make assignment > > > > > > outside the if statement. > > > > > > > > > > > > > > > > Sounds like a reasonable change. > > > > > > > > It is unclear how much changes to ISA code are welcomed. > > If changes to ISA code aren't welcomed, should these be marked obsolete in the MAINTIANERS file? I think so, but think that "Odd Fixes" better describes that Rafael wrote. Thanks

1 0

Re: [PATCH] drivers: pnp: proc.c: Removed unnecessary varibles
by Leon Romanovsky April 26, 2021

April 26, 2021

On Mon, Apr 26, 2021 at 02:00:58PM +0200, Rafael J. Wysocki wrote: > On Mon, Apr 26, 2021 at 6:57 AM Leon Romanovsky <leon(a)kernel.org> wrote: > > > > On Fri, Apr 23, 2021 at 03:08:03PM -0600, Shuah Khan wrote: > > > On 4/22/21 12:03 PM, Anupama K Patil wrote: > > > > de, e are two variables of the type 'struct proc_dir_entry' > > > > which can be removed to save memory. This also fixes a coding style > > > > issue reported by checkpatch where we are suggested to make assignment > > > > outside the if statement. > > > > > > > > > > Sounds like a reasonable change. > > > > It is unclear how much changes to ISA code are welcomed. > > Real fixes and obvious cleanups are, not much more than that. While first part is easy to determine, the second one is more blurry. > > > According to the Wikipedia, even Windows Vista disabled ISA PnP by default. > > https://en.wikipedia.org/wiki/Legacy_Plug_and_Play#Specifications > > It is indeed unclear how many systems with this interface still run > Linux, but as long as the code is in the tree, there's nothing wrong > with attempting to improve it. There's no assurance that all such > patches will be applied, though. > > Thanks!

2 1

Device driver .shutdown() VS .remove()
by Luca Ceresoli April 26, 2021

April 26, 2021

Hello, despite having been searching for documentation I couldn't find out the exact and detailed difference between the .shutdown() and .remove() calls in struct device_driver. My best understanding follows. Any amendment or clarification would be appreciated, and why not it might end up in improving the docs. The different intent is kind of clear: remove() is called when the device is disconnected or otherwise removed from the system, and also when the driver is removed (which can only happen by unloading a kernel module, I think). shutdown() is called during reboot and shutdown. remove() is _not_ called during shutdown and reboot. shutdown() is not called on device or driver removal. Things get more blurred when trying to understand what each of the two should do. Definitely both must stop the device from producing any events to the rest of the system: stop DMAs, stop anything that would trigger interrupts etc. remove() should also "turn off" the device, but it's probably a good idea to do in shutdown() as well in order to not leave peripherals unnecessarily powered while rebooting. remove() must definitely free any allocated resources, which would be useless in shutdown(). >From the above it looks like the shutdown() actions must be a subset of remove() actions. How much of my understanding is correct? Thanks. -- Luca

2 2

Re: [PATCH] drivers: pnp: proc.c: Handle errors while attaching devices
by Valdis Klētnieks April 24, 2021

April 24, 2021

On Sun, 25 Apr 2021 01:13:01 +0530, Anupama K Patil said: > Changed sprintf() to the kernel-space function scnprintf() as it returns > the actual number of bytes written. > + if (!bus->procdir) { > + scnprintf(name, 16, "%02x", bus->number); > + scnprintf(name, 16, "%02x", dev->number); Why do this when you don't *use* the number of bytes written, but instead ignore the value returned? For bonus points: Given the %02x format, under what conditions can it return a value other than 2?

1 0

Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES:
by Jules Irenge April 24, 2021

April 24, 2021

Hi My git sendmail -1 command , throws the above error. Can anyone help me solve it ? Jules Net::SMTP>>> Net::SMTP(3.13) Net::SMTP>>> Net::Cmd(3.13) Net::SMTP>>> Exporter(5.74) Net::SMTP>>> IO::Socket::IP(0.41) Net::SMTP>>> IO::Socket(1.43) Net::SMTP>>> IO::Handle(1.42) Net::SMTP=GLOB(0x55f23ecd2bf0)<<< 220 smtp.gmail.com ESMTP qu23sm2565932ejb.1 - gsmtp Net::SMTP=GLOB(0x55f23ecd2bf0)>>> EHLO earthie.\040none\041 Net::SMTP=GLOB(0x55f23ecd2bf0)<<< 501-5.5.4 HELO/EHLO argument "earthie.\040none\041" invalid, closing connection. Net::SMTP=GLOB(0x55f23ecd2bf0)<<< 501 5.5.4 https://support.google.com/mail/?p=helo qu23sm2565932ejb.1 - gsmtp Net::SMTP=GLOB(0x55f23ecd2bf0)>>> HELO earthie.\040none\041 Net::SMTP: Net::Cmd::getline(): unexpected EOF on command channel: at /usr/libexec/git-core/git-send-email line 1539. Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=smtp.gmail.com encryption=tls hello=earthie.\040none\041 port=587 at /usr/libexec/git-core/git-send-email line 1566.

1 0

Importing the Japanese Shift-JIS encoding to the kernel's locale
by HerbalNekoTea April 24, 2021

April 24, 2021

Hi, i have kinda found a method a couple years ago to import the Japanese Shift-JIS encoding from Fedora/CentOS/RHEL/OpenSuse to any other distribution and i keep forgetting to maintain the sideloading method when the kernel update broke it. A lot of Japanese content for Windows, who are able to run into Wine, required Japanese Shift-JIS locale used mostly back in the days. Sadly, only the distros above have it in their file and nobody noticed for years. This is also a major reason why Japanese speaker never used Linux too much due to Linux never supporting Shift-JIS by default and one of the reason MacOS and Windows got a monopole there (Yeah, MacOS support it from FreeBSD). My main issue's idk what's the license of the locale itself. The license of the package from the Fedora repo state the following for that package "LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ and GPLv2+ with exceptions and BSD and Inner-Net and ISC and Public Domain and GFDL" which made me feel like it might had come from FreeBSD and might be BSD license... I am very unsure about it. Essentially, the reply from 2018 from this bugzilla mailing list was what i found to make it work. https://bugzilla.redhat.com/show_bug.cgi?id=136290 It would required to have a up to date fedora build and rip it from that location... Which's very inconveniant. Hence why i was hoping to have it supported by default by the kernel. It's kinda my first time to the kernel mailing list, hence why i am posting in the newbie section to not annoy anybody in the more official channel. IDK either how i can contribute the patch. I really hope this local can be included by default upstream so it get supported for the Japanese user to have their classic game supported in Wine so Linux could spare them from Windows 10's current issue. -Regard, HerbalNekoTea

3 3

preemptible spinlock?
by 유형곤 April 24, 2021

April 24, 2021

I'm learning how spinlock works. I think the main idea spinlock disables preemption is, the other process that's spinning on the lock can acquire lock. but in some implementations of spinlock, like qspinlock in x86 (or mcs lock), I think there's no need to disable preemption. because processes waiting for lock cannot acquire the lock before the lock holder hand over to other process. is enabling preemption in such spinlock a bad idea?

4 3

TCP syn flooding protection
by JeongHwan Kim April 23, 2021

April 23, 2021

Hi, everyone I'm testing packet flooding test with old kernel version 2.6.30. My board experienced process starvation when injecting ICMP flood with hping3 tool. I modified softirq invocation routine to launch ksoftirqd instead of executing do_softirq and I limitted the speed of ethernet phy to accept below 10Mbps. It seems that the board can process flooding ICMP packets of 10Mbps, but the board cannot process against TCP/UDP packet flooding, the speed of processes become slow down. IPtabls of which rule is dropping all TCP/UDP packet does not improve the situation. How can I protect the TCP/UDP flooding in my environment. Thanks in advance. Kim

2 1

USB resets
by Jorge Fernandez Monteagudo April 22, 2021

April 22, 2021

Hi all, I'm using an ancient 4.17.1 kernel and I'm seeing an weird USB behavior. A touchscreen device is been detected and disconnected in a 4 seconds pattern. # dmesg | grep 1.3.2[ 2.170041] usb 1-1.3.2: new full-speed USB device number 6 using ehci-pci [ 2.254868] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0001/input/input2 [ 2.254958] hid-multitouch 0003:29BD:4101.0001: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 6.776320] usb 1-1.3.2: USB disconnect, device number 6 [ 6.955040] usb 1-1.3.2: new full-speed USB device number 7 using ehci-pci [ 7.039215] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0002/input/input4 [ 7.039306] hid-multitouch 0003:29BD:4101.0002: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 11.383830] usb 1-1.3.2: USB disconnect, device number 7 [ 11.642043] usb 1-1.3.2: new full-speed USB device number 8 using ehci-pci [ 11.726858] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0003/input/input6 [ 11.726947] hid-multitouch 0003:29BD:4101.0003: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 16.247185] usb 1-1.3.2: USB disconnect, device number 8 [ 16.426042] usb 1-1.3.2: new full-speed USB device number 9 using ehci-pci [ 16.510970] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0004/input/input8 [ 16.511067] hid-multitouch 0003:29BD:4101.0004: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 20.854572] usb 1-1.3.2: USB disconnect, device number 9 [ 21.112042] usb 1-1.3.2: new full-speed USB device number 10 using ehci-pci [ 21.197973] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0005/input/input10 [ 21.198072] hid-multitouch 0003:29BD:4101.0005: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 25.717651] usb 1-1.3.2: USB disconnect, device number 10 [ 25.895018] usb 1-1.3.2: new full-speed USB device number 11 using ehci-pci [ 25.979810] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0006/input/input12 [ 25.979909] hid-multitouch 0003:29BD:4101.0006: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 30.325789] usb 1-1.3.2: USB disconnect, device number 11 [ 30.588021] usb 1-1.3.2: new full-speed USB device number 12 using ehci-pci [ 30.673335] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0007/input/input14 [ 30.673381] hid-multitouch 0003:29BD:4101.0007: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 35.188772] usb 1-1.3.2: USB disconnect, device number 12 [ 35.366040] usb 1-1.3.2: new full-speed USB device number 13 using ehci-pci [ 35.451447] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0008/input/input16 [ 35.451498] hid-multitouch 0003:29BD:4101.0008: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 39.795933] usb 1-1.3.2: USB disconnect, device number 13 [ 40.055019] usb 1-1.3.2: new full-speed USB device number 14 using ehci-pci [ 40.139578] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0009/input/input18 [ 40.139626] hid-multitouch 0003:29BD:4101.0009: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 44.659133] usb 1-1.3.2: USB disconnect, device number 14 [ 44.837018] usb 1-1.3.2: new full-speed USB device number 15 using ehci-pci [ 44.920784] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000A/input/input20 [ 44.920828] hid-multitouch 0003:29BD:4101.000A: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 49.266523] usb 1-1.3.2: USB disconnect, device number 15 [ 49.550012] usb 1-1.3.2: new full-speed USB device number 16 using ehci-pci [ 49.634659] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000B/input/input22 [ 49.634706] hid-multitouch 0003:29BD:4101.000B: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 54.129875] usb 1-1.3.2: USB disconnect, device number 16 [ 54.305025] usb 1-1.3.2: new full-speed USB device number 17 using ehci-pci [ 54.390293] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000C/input/input24 [ 54.390342] hid-multitouch 0003:29BD:4101.000C: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 58.737665] usb 1-1.3.2: USB disconnect, device number 17 [ 58.996040] usb 1-1.3.2: new full-speed USB device number 18 using ehci-pci [ 59.079931] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000D/input/input29 [ 59.079981] hid-multitouch 0003:29BD:4101.000D: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0 [ 63.932020] usb 1-1.3.2: reset full-speed USB device number 18 using ehci-pci After 12 disconnect messages sometime I see a reset message, like the shown in this trace, and the touch is not working. Sometime this reset it's not send and the touchs works ok. My guess is that the Xorg sometime runs and get access to touch before this 4 or 5 second watchdog is executed and then the touch is not disconnected this last time... Anybody has some experience in this kind of USB errors? Is it a known behavior modified in a more recent kernel? Any hint is welcome Jorge

2 5