February 2015 - kernelnewbies@kernelnewbies.org

60KB Shared library memory on /proc/<pid>/maps
by yaniv levy Feb. 16, 2015

Feb. 16, 2015

Hi, In a quest for understanding RAM requirements of system processes, I arrived to analysis of /proc/<pid>/maps. I have noticed that many shared libraries have exactly 60KB space allocated in virtual memory right after the code, with permissions "---p", meaning non-executable, non-writable, non-readable and private. My guess is that it is not the .text .data or .bss sections of the shared library because it is not r/w/x. What is it? can it be reduced? When using /proc/<pid>/smpas to further dive in, I haven't seen it in RSS (Resident Memory), so one can claim that it is of no importance to RAM use. I tried to relate it to the executable or shared library sections by using objdump or readlef, but I could not find a section that's 60KB. For example: 76d2d000-76d94000 r-xp 00000000 1f:00 439 /lib/libc.so.0 76d94000-76da3000 ---p 00000000 00:00 0 (What's that?) 76da3000-76da4000 r--p 00066000 1f:00 439 /lib/libc.so.0 76da4000-76da5000 rw-p 00067000 1f:00 439 /lib/libc.so.0 76da5000-76dab000 rw-p 00000000 00:00 0 Thank you

1 0

Download patch from email.
by Anand Moon Feb. 15, 2015

Feb. 15, 2015

Hi All, I have configured mutt as email client. https://github.com/narkoleptik/dotfiles/blob/master/.muttrc But my configuration don't allow me to download Linux patch's from email. Please some one could point out the configuration or suggest other email client. -Anand Moon

3 5

Replacing "-custom" in my New Kernel development configuration
by s.rawat Feb. 12, 2015

Feb. 12, 2015

Hello, I recently built the 3.18.5 kernel according to instruction on the linuxkernel newbie page .I used /sbin/installkernel script to install the modules and updated the grub.cnf. On a reboot i get option 3.18.5[b]-custom[/b] and booted in.But now since I am modifying the kernel and needed headers in /user/src for the same kernel name i am using i.e 3.18.5 , but uname-r gives 3.18.5[b]-custom[/b].I can still install headers with the name 3.18.5 and rename it to 3.18.5-custombut how is there any other way out to fix this.If I could replace "-custom" in all the places or do I have to do it manually - in grub, all all other places?I dont know how many places it has been reference as "-custom". I might have taken a wrong route i guess :S ! Have I?? Rgds,S

4 7

Fwd: Fwd: Getting path in inode_permission
by noyb noybee Feb. 12, 2015

Feb. 12, 2015

Apologies for the late reply. On Sat, Feb 7, 2015 at 8:52 AM, <Valdis.Kletnieks(a)vt.edu> wrote: > On Sat, 07 Feb 2015 07:27:13 +0530, noyb noybee said: > >> I am trying to enhance the security features of the chroot "jail"(I >> know it wasn't built for the purpose). I am trying to prevent access >> to files outside the "jail" unless they specify a specific > > The right thing to do is design the jail so it *never* references files > outside. > >> passsphrase. Whenever an inode is accessed, inode_persmission is >> called. I get the pid of the calling process by current->pid in the >> hook and check if it is a child of the original process for which > > Bzzt! Wrong. Trivially beatable - all I have to do is double-fork, > exit the child process, the grandchild gets reparented to PID 1, > and your check fails. You are correct. I missed out on that fact. Well, there's still a workaround. I will put in some kind of data in the security structure of task_struct as soon as it is created. > >> chroot was run. If yes + if this process hasn't specified a passphrase >> + the path of the inode shows that it is outside the "jail", the >> request is blocked. I am also blocking all mounts in the "jail". > > Plus the whole passphrase thing is probably equally easy to defeat. (Hint - > how does the passphrase get passed to the kernel in the first place?) I am planning to create a new system call for that and I am not sure how that would be insecure. Please correct me if I am wrong. What you're saying is definitely simpler than my approach but it probably violates some POSIX standards(including chdir in chroot) which I don't want to. Also, I aim for my tool to be just a simple addendum to the traditional system call rather than adding a completely new call to handle the entire process.

2 7

documentation for kmem_cache API
by Jeff Haran Feb. 12, 2015

Feb. 12, 2015

Hi, If anybody is aware of up to date documentation describing the kmem cache API, please post a link. The docs I have been able to find so far do not seem to match the API provided by the code. Thanks, Jeff Haran

1 0

Re: Question on MSI support in PCI and PCI-E devices
by Andrey Utkin Feb. 12, 2015

Feb. 12, 2015

2015-02-12 16:48 GMT+02:00 Stephen Hemminger <stephen(a)networkplumber.org>: > On Wed, 11 Feb 2015 18:19:00 +0000 > Andrey Utkin <andrey.krieger.utkin(a)gmail.com> wrote: > >> Is it true that _every_ PCI or PCI Express device supporting MSI is >> indicated by some mention of MSI in "lspci -v", and if there's no such >> mention, it surely doesn't support MSI? >> > > Look at kernel source (drivers/pci/msi.c) function pci_msi_supported > there are many things which can block MSI. > > There can be cases where PCI quirks in kernel block MSI > because for example the device supports MSI, but the motherboard > BIOS is broken. This only happens on really old systems. Thank you for your reply. However, I was more interested in the case when lspci for device doesn't mention MSI at all, so I wonder if it makes sense to try to enable it in the driver at all. 04:05.0 Multimedia video controller: Bluecherry BC-H16480A 16 port H.264 video and audio encoder / decoder Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (250ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at faff0000 (32-bit, prefetchable) [size=64K] Kernel driver in use: solo6x10 We have such cards, and we have issues with them - at some moment they stop producing interrupts. No matter whether they share interrupt number or not. There was a recent commit from Krzysztof Hałasa (3c787b108fe0d1c341a76e718a25897ae14673cf) which improved things, but the issue still happens regularly on some setups. Now I've tried the following change, i've introduced such a loop which I see in bt8xx and ddbridge drivers. This also didn't help. So I'm out of ideas now (any comments are highly appreciated!); I have read about MSI, that this interrupts transmission mechanism is more reliable and fast, but from lspci output it is not clear whether our cards support MSI at all. --- a/drivers/media/pci/solo6x10/solo6x10-core.c +++ b/drivers/media/pci/solo6x10/solo6x10-core.c @@ -100,10 +100,13 @@ static irqreturn_t solo_isr(int irq, void *data) struct solo_dev *solo_dev = data; u32 status; int i; + int handled = 0; + while (1) { status = solo_reg_read(solo_dev, SOLO_IRQ_STAT); if (!status) - return IRQ_NONE; + break; + handled++; /* Acknowledge all interrupts immediately */ solo_reg_write(solo_dev, SOLO_IRQ_STAT, status); @@ -129,7 +132,11 @@ static irqreturn_t solo_isr(int irq, void *data) if (status & SOLO_IRQ_G723) solo_g723_isr(solo_dev); - return IRQ_HANDLED; + } + + if (handled > 1) + solo_dev->isr_more_laps++; + return IRQ_RETVAL(handled); } static void free_solo_dev(struct solo_dev *solo_dev) @@ -232,6 +239,16 @@ static ssize_t p2m_timeouts_show(struct device *dev, return sprintf(buf, "%d\n", solo_dev->p2m_timeouts); } +static ssize_t isr_more_laps_show(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct solo_dev *solo_dev = + container_of(dev, struct solo_dev, dev); + + return sprintf(buf, "%d\n", solo_dev->isr_more_laps); +} + static ssize_t sdram_size_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -415,6 +432,7 @@ static const struct device_attribute solo_dev_attrs[] = { __ATTR_RO(input_map), __ATTR_RO(intervals), __ATTR_RO(sdram_offsets), + __ATTR_RO(isr_more_laps), }; static void solo_device_release(struct device *dev) index d19c0ae..dffd7d7 --- a/drivers/media/pci/solo6x10/solo6x10-enc.c +++ b/drivers/media/pci/solo6x10/solo6x10-enc.c @@ -28,7 +28,7 @@ #define VI_PROG_HSIZE (1280 - 16) #define VI_PROG_VSIZE (1024 - 16) -#define IRQ_LEVEL 2 +#define IRQ_LEVEL 3 static void solo_capture_config(struct solo_dev *solo_dev) { index 6c9bc70..4799ea2 --- a/drivers/media/pci/solo6x10/solo6x10.h +++ b/drivers/media/pci/solo6x10/solo6x10.h @@ -277,6 +277,8 @@ struct solo_dev { spinlock_t slock; int old_write; struct list_head vidq_active; + + int isr_more_laps; }; static inline u32 solo_reg_read(struct solo_dev *solo_dev, int reg) -- Andrey Utkin

1 0

Amazon VPS, long UDP packets are seen by sniffer, but don't reach application
by Andrey Utkin Feb. 12, 2015

Feb. 12, 2015

This is experienced with l3.large, t2.micro with Ubuntu 14. I believe we don't have any special settings over system defaults. We send a large datagram from remote host, e.g. with such trivial app in python: import socket UDP_IP = "123.123.123.123" # remote host IP UDP_PORT = 33333 MESSAGE = """ .....0010......0020......0030......0040......0050......0060......0070......0080......0090......0100 .....0110......0120......0130......0140......0150......0160......0170......0180......0190......0200 .....0210......0220......0230......0240......0250......0260......0270......0280......0290......0300 .....0310......0320......0330......0340......0350......0360......0370......0380......0390......0400 .....0410......0420......0430......0440......0450......0460......0470......0480......0490......0500 .....0510......0520......0530......0540......0550......0560......0570......0580......0590......0600 .....0610......0620......0630......0640......0650......0660......0670......0680......0690......0700 .....0710......0720......0730......0740......0750......0760......0770......0780......0790......0800 .....0810......0820......0830......0840......0850......0860......0870......0880......0890......0900 .....0910......0920......0930......0940......0950......0960......0970......0980......0990......1000 .....1010......1020......1030......1040......1050......1060......1070......1080......1090......1100 .....1110......1120......1130......1140......1150......1160......1170......1180......1190......1200 .....1210......1220......1230......1240......1250......1260......1270......1280......1290......1300 .....1310......1320......1330......1340......1350......1360......1370......1380......1390......1400 .....1410......1420......1430......1440......1450......1460......1470......1480......1490......1500 .....1510......1520......1530......1540......1550......1560......1570......1580......1590......1600 .....1610......1620......1630......1640......1650......1660......1670......1680......1690......1700 .....1710......1720......1730......1740......1750......1760......1770......1780......1790......1800 .....1810......1820......1830......1840......1850......1860......1870......1880......1890......1900 .....1910......1920......1930......1940......1950......1960......1970......1980......1990......2000""" print "UDP target IP:", UDP_IP print "UDP target port:", UDP_PORT print "message:", MESSAGE sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.sendto(MESSAGE, (UDP_IP, UDP_PORT)) Then we listen on that port with such trivial python app: import socket UDP_IP = "172.31.4.102" # local ip UDP_PORT = 33333 sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((UDP_IP, UDP_PORT)) while True: data, addr = sock.recvfrom(0x10000) print "received message:", data Meanwhile, we monitor the traffic with e.g. ngrep: ngrep -t -e -d any -W byline -O large_udp.pcap port 33333 or '(ip[6:2]' '&' '0x1fff)' '!=' '0' (the part after "or" catches segments of segmented packets) About the host: # uname -a Linux hostname 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Also linux-image-3.13.0-36-generic and linux-image-3.13.0-45-generic behave in same way. What we see: - ngrep shows the packets with correct contents. All segments are delivered. - application doesn't get any data at all Rarely dmesg shows such messages: [ 102.161679] UDP: bad checksum. From 123.123.123.124:56439 to 172.31.4.102:33333 ulen 2008 but it is logged really rarely, so this is surely not what happens on every packet transmission. This test works fine on e.g. cheapest DigitalOcean VPS. I am concerned with this issue because rtpengine software has UDP interface. So on Amazon hosts this interface works only within localhost, and I cannot distribute software to different nodes. Any thoughts? What's wrong, how to fix? -- Andrey Utkin

1 0

HID Custom Sensor driver in linux kernel
by s.rawat Feb. 12, 2015

Feb. 12, 2015

I am reading the HID sensor hub code on lxr <http://lxr.free-electrons.com/source/drivers/hid/hid-sensor-hub.c> and found that there is no driver code for hid custom sensor.Is this driver non existent.Hid custom sensor is a custom sensor implemented in the device firmware. I have a sensor device to which i can talk in windows using hid dlls ,I can even read custom fields of a custom sensor of a device through windows apis. I want to do the same in linux.I can read the accelerometer, gyroscope and magnetometer data through a c application <https://github.com/pfps/yoga-laptop> in Linux.But I am unable to do so for a custom sensors due to un-availability of the HID custom sensor driver.Does it exist or exist by some other name?. Rgds S

2 3

workqueues - how to use them correctly
by Roshan A Feb. 11, 2015

Feb. 11, 2015

hi all, My question is regarding the correct use of workqueues. I have a driver which queues a work item in the interrupt handler. The bottom half function ( the workitem -function ) does have proper locking ( mutex ) in place for atomicity. With this setup, since the interrupts are enabled, it's possible to have a scenario where, when one workitem is being executed, another can be queued up, which results in the workitems being executed in parallel, however since there is a mutex, one thread will sleep. is this particular scenario considered bad or discouraged ? Thank you, -Roshan

4 5

Question on MSI support in PCI and PCI-E devices
by Andrey Utkin Feb. 11, 2015

Feb. 11, 2015

Is it true that _every_ PCI or PCI Express device supporting MSI is indicated by some mention of MSI in "lspci -v", and if there's no such mention, it surely doesn't support MSI? -- Andrey Utkin

1 0