While running the function in kernel space
kernel_sock_ioctl(socket, FIONBIO, &on)
it returns error ENOIOCTLCMD 515 /* No ioctl command */
But when executing the same function in userspace
ioctl(s, FIONBIO, &on)
it succeeds
Why is ioctl missed for the same function in kernel space and how to handle it?
How to apply FIONBIO ioctl in kernel space?
Related
Let me describe what sysfs does : its a pseudo file system where files, directories are generated by the core kernel or kernel drivers. And these files have read/write access and are a mechanism to control certain kernel level parameters by user space (seperate from ioctls and file operations).
Sysfs from Kernel.org
Sysfs from Wikipedia
The following is an example of how userspace interacts with sysfs.
$ cat /sys/modules/mydriver/foo_count
1
$ echo "2" > /sys/modules/mydriver/foo_count $ cat /sys/modules/mydriver/foo_count
2
The cat command will trigger a read via the show_foo_count() kernel routine, while the echo will trigger a write via the store_foo_count() routine
The following is how the kernel driver/module might intercept the user space activity.
static ssize_t show_foo_count(struct kobject *kobj,struct kobj_attribute *attr,
char *buf)
{
/* This will perform a read operation and contents of buf will be updated*/
...
}
static ssize_t store_foo_count(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf,size_t len)
{
/* Contents are read from buf and stored within the driver's context/state */
...
}
A good example is here
How can one achieve the same sysfs usage on windows drivers ?
I see the following windows concepts, but I am unable to map them to be the equivalent of syfs :
A. Device Objects
B. File Object
I have a full dump of a VM with windows 10 installed. This dump was taken from a hard hanged system, frozen mouse and keyboard, totally unresponsive.
While analyzing I found that there are no thread in running or ready state. No deadlocks. Only suspicious thing is that there are a lot of thread waiting for a reply from ALPC and also there is page fault pattern in as lot of threads that looks like this:
ffffbc0f`151380f0 fffff805`1e4e081c Ntfs!NtfsNonCachedIo+0x4ea
ffffbc0f`151383b0 fffff805`1e4df8bc Ntfs!NtfsCommonRead+0xd2c
ffffbc0f`151385b0 fffff805`19687d3a Ntfs!NtfsFsdRead+0x1fc
ffffbc0f`15138680 fffff805`19687ce7 nt!IopfCallDriver+0x46
ffffbc0f`151386c0 fffff805`1d926ccf nt!IofCallDriver+0x17
ffffbc0f`151386f0 fffff805`1d9248d3 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
ffffbc0f`15138760 fffff805`19687d3a FLTMGR!FltpDispatch+0xa3
ffffbc0f`151387c0 fffff805`19687ce7 nt!IopfCallDriver+0x46
ffffbc0f`15138800 fffff805`196215b2 nt!IofCallDriver+0x17
ffffbc0f`15138830 fffff805`196221e2 nt!IoPageReadEx+0x1e6
ffffbc0f`151388a0 fffff805`19622eee nt!MiIssueHardFaultIo+0xb6
ffffbc0f`151388f0 fffff805`19666566 nt!MiIssueHardFault+0x48e
ffffbc0f`151389f0 fffff805`197aba1e nt!MmAccessFault+0x276
ffffbc0f`15138b00 00007ffd`2e42ec10 nt!KiPageFault+0x35e (TrapFrame # ffffbc0f`15138b00)
also almost every thread (maybe I've seen 1 or 2 that don't) in every process ends with this:
ffffbc0f`15d08df0 fffff805`1966aad4 nt!KiSwapContext+0x76
ffffbc0f`15d08f30 fffff805`196657ca nt!KiSwapThread+0x190
ffffbc0f`15d08fa0 fffff805`19666fb0 nt!KiCommitThreadWait+0x13a
ffffbc0f`15d09050 fffff805`1e4e261a nt!KeWaitForSingleObject+0x140
I have one particular example of a thread with a page fault belonging to a prl_tools_service.exe (which is Parallels VM related service) that has same pattern and when looking into trap frame at the moment of KiPageFault there was an attempt to get value from an address in eax and in trap frame rax=0000000000000001 which can't be a valid address and I can't see how this page fault can be resolved.
IRQLs of both processors are LOW_LEVEL
The question, basically, is - where should I look for any faults since there must be a kernel problem (hence mouse and keyboard freeze) and how do I find wether this example of page fault pattern could stall the kernel.
Since the question is pretty vague any kind of response, a direction where to look, a hint - every thing will be much appreciated
UPD: as requested by Lieven Keersmaekers and blabb here is !analyze -hang output:
0: kd> !analyze -hang
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
Scanning for threads blocked on locks ...
Cannot get _ERESOURCE type
BUGCHECK_CODE: 0
BUGCHECK_P1: 0
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
PROCESS_NAME: System
ERROR_CODE: (NTSTATUS) 0x45474150 - <Unable to get error code text>
SYMBOL_NAME: nt!PpmIdleGuestExecute+1d
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
FAILURE_BUCKET_ID: 0x0_STACKPTR_ERROR_nt!PpmIdleGuestExecute
FAILURE_ID_HASH: {94784d45-ed21-c95f-fc42-87fec626bbee}
Followup: MachineOwner
---------
all,
I encounter a problem when use systemtap script.
I don't know how to get the host name of kill signal sender in systemtap script.
for example. I am execute kill -9 xclock_process_pid in server 'sf1'. at the same time, I run 1.stap -x xclock_process_pid to monitor xclock,
is there any method to obtain the server name 'sf1' in systemtap script when send a kill -9 xclock_process_pid in 'sf1'?
but I am encounter some problem. my 1.stap is shown below:
#!/usr/bin/env stap
function hostname:string () %{
STAP_RETURN(current->nsproxy->uts_ns->name.nodename);
%}
probe oneshot {
log(hostname())
}
when I run 'stap -g 1.stap' will reprot the following error Could you help me? semantic error: probe point mismatch at position 0 (alternatives: __nfs __scheduler __signal __tcpmib __vm _linuxmib _signal _sunrpc _syscall _vfs begin begin(number) end end(number) error error(number) generic ioblock ioblock_trace ioscheduler ioscheduler_trace ipmib irq_handler kernel kprobe kprocess linuxmib module(string) nd_syscall netdev never nfs nfsd perf process process(number) process(string) procfs procfs(string) scheduler scsi signal socket softirq stap staprun sunrpc syscall tcp tcpmib timer tty udp vfs vm workqueue): identifier 'oneshot' at systemtap.stap:87:7 while resolving probe point oneshot source: probe oneshot { ^ Pass 2: analysis failed. Try again with another '--vp 01' option.
In other words, you're asking how to get the hostname of the current machine. A TCP/IP-level hostname is not in reach. The sethostname(2) level name is not easy to reach, being hidden inside kernel variables behind locked utsname()-> fields.
If safety were not a problem, you could do it via an embedded-C function for 4.8 era kernels:
function hostname:string () %{
STAP_RETURN(current->nsproxy->uts_ns->name.nodename);
%}
probe oneshot {
log(hostname())
}
that you would run with stap -g ... (guru mode).
On OS X El Capitan, my log file system.log feels with hundreds of the following lines at times
03/07/2016 11:52:17.000 kernel[0]: hfs_clonefile: cluster_read failed - 34
but there is no indication of the process where this happens. Apart from that, Disk Utility could not find any fault with the file system. But I would still like to know what is going on and it seems to me that dtrace should be perfectly suited to find out that faulty process but I am stuck. I know of the function return probe but it seems to require the PID, e.g.
dtrace -n 'pidXXXX::hfs_clonefile:return { printf("ret: %d", arg1); }'
Is there a way to tell dtrace to probe all processes? And then how would I print the process name?
You can try something like this (I don't have access to an OS X machine to test it)
#!/usr/sbin/dtrace -s
# pragma D option quiet
fbt::hfs_clonefile:return
/ args[ 1 ] != 0 /
{
printf( "\n========\nprocess: %s, pid: %d, ret value: %d\n", execname, pid, args[ 1 ] );
/* get kernel and user-space stacks */
stack( 20 );
ustack( 20 );
}
For the fbt probes, args[ 1 ] is the value returned by the function.
The dTrace script will print out the process name, pid, and return value from hfs_clonefile() whenever the return value is not zero. It also adds the kernel and user space stack traces. That should be more than enough data for you to find the source of the errors.
Assuming it works on OS X, anyway.
You can use the syscall provider rather than the pid provider to do this sort of thing. Something like:
sudo dtrace -n 'syscall::hfs_clonefile*:return /errno != 0/ { printf("ret: %d\n", errno); }'
The above command is a minor variant of what's used within the built-in DTrace-based errinfo utility. You can view /usr/bin/errinfo in any editor to see how it works.
However, there's no hfs_clonefile syscall, as least as far as DTrace is concerned, on my El Capitan (10.11.5) system:
$ sudo dtrace -l -n 'syscall::hfs*:'
ID PROVIDER MODULE FUNCTION NAME
dtrace: failed to match syscall::hfs*:: No probe matches description
Also, unfortunately the syscall provider is prevented from tracing system processes by the System Integrity Protection feature introduced with El Capitan (macOS 10.11). So, you will have to disable SIP which makes your system less secure.
I have some question about Linux kernel and GPIOs. I know that in Linux everything is file so when I do something like
echo 30 > /sys/class/gpio/export
and
echo 1 > /sys/class/gpio/gpio30/value
what really happens? I mean how does sysfs handle that? Does it call system calls implemented in gpiolib?
The gpiolib registers the value attribute in this way:
static const DEVICE_ATTR(value, 0644, gpio_value_show, gpio_value_store);
It creates a device attribute named value, with permission 644; on read it calls gpio_value_show, on write it calls gpio_value_store
What sysfs does, is to redirect read and write to the correspondent function of a sysfs attribute.