In MINIX 3.2.1, I want to create a new system call in VFS server which will be given a filename as a parameter and will print this certain file's inode number.
So in order to retrieve the inode of the file by its name I want to use the default system call:
int stat(char *name,struct stat *buffer)
http://minix1.woodhull.com/manpages/man2/stat.2.html
in the body of my new system call handler which is
int mycall_1(void);
inside `/usr/src/servers/vfs/misc.c
But when I test the new system call, at the point where the stat system call should be invoked, it actually won't and instead it's printing the message:
sys_call: ipc mask denied SENDREC from 1 to 1
After some research, I found that this possibly happens because the VFS server tries to send a message to itself, as stat is actually implemented inside VFS server, and so ipc mask denied this sendrec() call. So I have to edit some configuration file in order to give the right permission for this communication to happen.
But I'm not sure if what I have understood is right and also do not know which file should Ι edit to give the appropriate permissions. So, if someone could enlighten me on this issue, I would be grateful.
Thanks in advance.
You understood it correctly. But the solution is not to continue "fixing the permissions" which are here just to prevent to shot yourself in the foot: it would only allow the system to more badly brocken.
Rather, you need to perform the steps that VFS do when it services a STAT request, starting after it cracked the message.
Related
This question already has an answer here:
ioctl giving Invalid Argument
(1 answer)
Closed 5 years ago.
I want to send a file descriptor of a tcp socket from process A to process B, so that process B can create another tcp socket with the same file descriptor.
the idea is exactly the same as passing file descriptors
the key function call is the following:
ioctl(fd, I_SENDFD, fd_to_send);
but it always returns EPERM /* Operation not permitted */
I verified the domain socket file descriptor fd is working, as I could send normal messages through that fd.
I don't know what's wrong. I googled, nobody seems to mention I_SENDFD has permission issue. I tried using "sudo" to run my programs. It still doesn't work.
I have also tried allowing everything for that file descriptorfcntl(fd_to_send, F_SETFL, S_IRWXU|S_IRUSR|S_IWUSR|S_IXUSR|S_IRWXG| S_IRGRP|S_IWGRP|S_IXGRP|S_IRWXO|S_IROTH|S_IWOTH|S_IXOTH);
doesn't work either.
how to fix?
I have found the answer to my question.
Linux doesn't support this, but still keeps the API, which is evil.
for details regarding this issue, see ioctl giving Invalid Argument
here is a workaround solution: Can I share a file descriptor to another process on linux or are they local to the process?
(which I haven't tried)
Please, help to solve the problem with communication establishment between PC and 1211C (6ES7-211-1BD30-0XB0 Firmware: V 2.0.2). I feel that I've made a stupid mistake somewhere, but can't figure out where exactly it is.
So, I'm using function TRCV_С...
The configuration seems to be okay:
When i set the CONT=1, the connection establishes without any problems...
But, when i set EN_R=1, I'm getting "error 893A".
That's what I have in my diagnostic buffer: (DB9 - is a block where the received data is supposed to be written)
There is an explanation given for "893A" in the manuals: Parameter contains the number of a DB that is not loaded. In diag. buffer its also written that DB9 is not loaded. But in my case it is loaded! So what should I do in this case?
it seems that DB were created or edited manually due to which they are miss aligned with FB instances try removing and DB and FB instances and then add again instances of FBs with automatically created DBs and do a offline dowonload
I am trying to read/write to a I/O Memory Register of a platform device but the system hangs as soon as it goes to the line where read/write is performed.
I was able to check the following:
request_mem_region returns OK
the correct physical addr was requested (ioremap is OK)
a valid logical address is returned; used this to read the
register; ioread32(logical_addr)
I am quite new to the linux kernel, is there a way that the I/O registers are disabled?
I checked /proc/iomem, and the memory region that I wish to access appears in the list.
Where to go from here?
I found the answer. Thank you for your response Longfield.
I forgot to check the name used by the driver. It didn't match the device name being registered. They should match.
I want to get file size I'm doing this:
my $filename=$query->param("upload_file");
my $filesize = (-s $filename);
print "Size: $filesize ";`
Yet it is not working. Note that I did not upload the file. I want to check its size before uploading it. So to limit it to max of 1 MB.
You can't know the size of something before uploading. But you can check the Content-Length request header sent by the browser, if there is one. Then, you can decide whether or not you want to believe it. Note that the Content-Length will be the length of the entire request stream, including other form fields, and not just the file upload itself. But it's sufficient to get you a ballpark figure for conformant clients.
Since you seem to be running under plain CGI, you should be able to get the request body length in $ENV{CONTENT_LENGTH}.
Also want to sanity check against possibly already having post max set (from perldoc CGI):
$CGI::POST_MAX
If set to a non-negative integer, this variable puts a ceiling on the size of
POSTings, in bytes. If CGI.pm detects a POST that is greater than the ceiling,
it will immediately exit with an error message. This value will affect both
ordinary POSTs and multipart POSTs, meaning that it limits the maximum size of
file uploads as well. You should set this to a reasonably high value, such as
1 megabyte.
The uploaded file is stashed in a tmp location on the server when the form is submitted, check the file size there.
Supply the value for $field.
my $upload_filehandle = $query->upload($field);
my $tmpfilename = $query->tmpFileName($upload_filehandle);
my $file_size = (-s $tmpfilename);
This has nothing to do with Perl.
You are trying to read the filesize of a file on the user's computer using commands that read files on your server, what you want can't be done using Perl.
This is something that has to be done in the browser, and looking briefly at these questions it's either very hard or impossible.
Your best bet is to allow the user to start the upload and abort if the file is too big.
If you want to check before you process the request, you might be better off checking on the web page that triggers the request. I don't think the web browser can do it on it's own, but if you don't mind Flash, there are many Flash upload tools that can check things like size (as well as file types) and prevent uploading.
A good one to start with is the YUI Uploader. Lots more here: What is the best multiple file JavaScript / Flash file uploader?
Obviously you would want to check on the server side too, but by the time the user has started sending the request to the server, you are already using up your CPU cycles and bandwidth.
Thanks everyone for your replies; I just found out why $filesize = (-s $filename); was not working before, it is due that I was checking file size while sending Ajax request and not while re submitting the page.That's why I was having size to be zero. I fixed that to submit the page and it worked. Thanks.
Just read this post but while checking the content-length is a good approximate pre-check you could also save the file to temporary folder and then perform any kind of check on it. If it doesn't meet your criteria just delete and don't send it to it's final destination.
Look at the perl documentation for file stats -X - perldoc.perl.org and stat-perldoc.perl.org. Also, you can look at this upload script which is doing the similar thing what you are trying to do.
How do I find out which thread is the owner of my Event handle in windbg:
I'm running
!handle 00003aec f
and get
Handle 00003aec
Type Event
Attributes 0
GrantedAccess 0x1f0003:
Delete,ReadControl,WriteDac,WriteOwner,Synch
QueryState,ModifyState
HandleCount 2
PointerCount 4
Name <none>
No object specific information available
back, and as there is no Name I haven't figured out how to get the owner out to prove which thread my thread is waiting on
[Edit] I must work against a dump as the original process needs to be restarted on the users machine, so can't debug a live session
The best discussion on the subject I've found so far is on this blog, but unfortunately we end up using different lock methods (I end up using WaitForMultipleObjectsEx and the description is for WaitForSingleObject), and he seems to have access to a live process
the stacktrace of my thread (the one that is blocked on something and where I'm looking for the current owner) is:
0:045> k9
ChildEBP RetAddr
1130e050 7c90e9ab ntdll!KiFastSystemCallRet
1130e054 7c8094e2 ntdll!ZwWaitForMultipleObjects+0xc
1130e0f0 79ed98fd kernel32!WaitForMultipleObjectsEx+0x12c
1130e158 79ed9889 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
1130e178 79ed9808 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
1130e1fc 79ed96c4 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
1130e24c 79ed9a62 mscorwks!Thread::DoAppropriateWait+0x40
1130e2a8 79e78944 mscorwks!CLREvent::WaitEx+0xf7
1130e2bc 7a162d84 mscorwks!CLREvent::Wait+0x17
1130e33c 7a02fd94 mscorwks!CRWLock::RWWaitForSingleObject+0x6d
1130e364 79ebd3af mscorwks!CRWLock::StaticAcquireWriterLock+0x12e
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9
Looking at the callstack it appears that the stack in question is using a ReaderWriterLock locking mechanism.
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9
Change to thread 9 and using sos.dll run !dso to dump out the managed ReaderWriterLock object. Then run !do on that the ReaderWriterLock object. I believe that there is an owning thread field that you can query. I will test it and see.
The old school way to determine this is to run ~*e !clrstack and examine all of the managed threads that are waiting on a readerwriter lock and then see if you can find the thread that has entered the same function but passed through the lock (ie. different offset)
Thanks,
Aaron
Note: Not sure if there is a way to link posts but this one is very similar to
How do I find the lockholder (reader) of my ReaderWriterLock in windbg
Use the !htrace command to get the thread ID. You must first, possibly at the start of the program, enable the collection of traces with !htrace -enable.
0:001> !htrace 00003aec
--------------------------------------
Handle = 0x00003aec - OPEN
Thread ID = 0x00000b48, Process ID = 0x000011e8
...
The above output is fictional, it will be different for your system. But it will give you the piece of information you need - the thread ID (0x00000b48 in my example).
I must work against a dump as the
original process needs to be restarted
on the users machine, so can't debug a
live session.
I am not 100% sure but I think this will work:
Attach to the process and run !htrace -enable
Detach from the process with qd. The executable will continue.
You can now take a dump file and use the above command - I think you will have the described results.
You can dig that out of a kernel dump.
Now, as far as kernel debugging goes, livekd from sysinternals should be sufficient but unfortunately it is only usable on a running system.
There's also a kernel mode memory acquisition tool which might be of use to take a dump with (in windbg's stead) for later inspection.
Otherwise, enabling handle tracing (!htrace -enable) and (if code unique to particular thread), the handle ownership could be concluded from a stack trace.
Here's the definitive answer I found. Never tried myself. You'll need live debugging to determine the owner though. But it's pretty quick.
http://weblogs.thinktecture.com/ingo/2006/08/who-is-blocking-that-mutex---fun-with-windbg-cdb-and-kd.html