Re: why iowrite32_rep() doesn't work, I have to use the iowrite32() with a loop
On 11/18/2017 11:50 PM, Max Filippov wrote:
> On Thu, Nov 16, 2017 at 12:12 PM, ayaka wrote:
>> #if 1
>> for (i = 0; i < count; i++) {
>> u32 *cur = (u32 *)buffer;
>> u32 pos = offset + i * 4;
>>
>> cur += i;
>> mpp_debug(DEBUG_SET_REG, "write reg[%03d]: %08x\n",
>> pos / 4, *cur);
>> iowrite32(*cur, mpp_dev->reg_base + pos);
>> }
>> #else
>> iowrite32_rep(mpp_dev->reg_base + offset, buffer, count);
>> mb();
>> for (i = 0; i < count; i++) {
>> u32 cur = 0;
>> u32 pos = offset / 4 + i;
>>
>> cur = ioread32(mpp_dev->reg_base + pos * 4);
>> pr_info("get reg[%03d]: %08x\n", pos, cur);
>> }
>> #endif
> The loop with iowrite32 writes consecutive u32 words from buffer
> to consecutive IO memory locations. But iowrite32_rep writes
> consecutive u32 words from buffer to the same IO memory location.
> So they do different things when count > 1.
>
Thank you I think that explain why it doesn't work.
What I want is a relaxed version of the io{read,write}32, as I don't
need to flush between I am writing the registers table into the
registers. I only want to flush the cache at the last and isolated
register which I will set later.
Is there any suggest about that?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Invoking a system call from within the kernel
On Sat, 18 Nov 2017 14:09:31 -0500, Demi Marie Obenour said: > Only whitelisted system calls would be allowed, such as open(), read(), > and write(). Async getuid() would not be allowed. Nor would async > exit() or exit_group(). You missed the point - If you allow async calls, you need to deal with the fact that this can change the semantics of things and introduce race conditions. What semantics does an async open() have? Under what conditions does open() take long enough that doing it asyncronously provides a benefit? What system calls are you going to allow to be async? (Hold that thought for a moment, we'll return to it...) > If an async call fails, the packet posted to the file descriptor > contains the negative error code. OK.. Was that a -5 error from async() itself, or a -5 from the async read()? > Many programs (such as Node.js, NGINX, Firefox, Chrome, and every other > GUI program) use an event loop architecture. To maintain > responsiveness, it is necessary to avoid blocking calls on the main > thread (the thread that runs the event loop). For filesystem > operations, this is generally done by doing the operation in a thread > pool. And somehow, all those event loops are able to work just fine without adding kernel infrastructure. Given that track record, you'll need to show a *large* benefit in order to get it into the kernel. Hint: kdbus didn't make it in. > There was a previous attempt to implement async system calls using the > AIO interface. Linus rejected it on the basis that an async system call > API should be more general. Do you have enough system calls to make it more general than AIO? pgp1HWUqu77ns.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Invoking a system call from within the kernel
On Sat, Nov 18, 2017 at 01:44:44PM -0500, valdis.kletni...@vt.edu wrote: > On Sat, 18 Nov 2017 13:15:27 -0500, Demi Marie Obenour said: > > > However, the ioctl I actually want to implement (see above) does the > > system call asynchronously. That isn???t possible using the existing > > APIs. > > Ever consider that it's because there's no clear semantics to what > executing an arbitrary syscall asyncronously even *means*? > > What doe an async getuid() mean? For bonus points, what does it > return if the program does an async getuid(), and then does a > setuid() call *before the async call completes*? > Only whitelisted system calls would be allowed, such as open(), read(), and write(). Async getuid() would not be allowed. Nor would async exit() or exit_group(). The only system calls that would be whitelisted for async use are those that could potentially block on I/O. “Block” is used in a general sense: it includes disc I/O as well as network I/O. > > What is the return value of an async call that fails? How is it > returned, and how do you tell if a negative return code is > from the async code failing, or the syscall failing? > If an async call fails, the packet posted to the file descriptor contains the negative error code. > > > See above :) Basically, I am trying to improve performance and reduce > > complexity of programs that need to do a lot of buffered file I/O. > > We already have an AIO subsystem for exactly this. And eventfd's, and > poll(), and a bunch of other stuff. > This actually works with poll()/epoll()/etc. Specifically, the device file descriptor becomes readable when a completion event is posted to it, indiating that an async system call has completed and its result is available. > > And they improve performance, but increase complexity. It's pretty > hard to make > > while (rc=read() > 0) > rc2 = write() > > less complex. Catching the return of an async call makes it more complex. > Many programs (such as Node.js, NGINX, Firefox, Chrome, and every other GUI program) use an event loop architecture. To maintain responsiveness, it is necessary to avoid blocking calls on the main thread (the thread that runs the event loop). For filesystem operations, this is generally done by doing the operation in a thread pool. Async system calls move the thread pool to the kernel. The kernel has system-wide information and perform optimizations regarding e.g. scheduling and threadpool size that userspace cannot. Furthermore, the kernel threadpool threads have no userspace counterparts, so they avoid requiring a userspace stack or other data structures. There was a previous attempt to implement async system calls using the AIO interface. Linus rejected it on the basis that an async system call API should be more general. Sincerely, Demi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Invoking a system call from within the kernel
On Sat, 18 Nov 2017 13:15:27 -0500, Demi Marie Obenour said: > However, the ioctl I actually want to implement (see above) does the > system call asynchronously. That isnât possible using the existing > APIs. Ever consider that it's because there's no clear semantics to what executing an arbitrary syscall asyncronously even *means*? What doe an async getuid() mean? For bonus points, what does it return if the program does an async getuid(), and then does a setuid() call *before the async call completes*? What is the return value of an async call that fails? How is it returned, and how do you tell if a negative return code is from the async code failing, or the syscall failing? > See above :) Basically, I am trying to improve performance and reduce > complexity of programs that need to do a lot of buffered file I/O. We already have an AIO subsystem for exactly this. And eventfd's, and poll(), and a bunch of other stuff. And they improve performance, but increase complexity. It's pretty hard to make while (rc=read() > 0) rc2 = write() less complex. Catching the return of an async call makes it more complex. pgpNa065hVa4J.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Invoking a system call from within the kernel
On Thu, Nov 16, 2017 at 10:54:24AM +0100, Greg KH wrote:
> On Wed, Nov 15, 2017 at 09:16:35PM -0500, Demi Marie Obenour wrote:
> > I am looking to write my first driver. This driver will create a single
> > character device, which can be opened by any user. The device will
> > support one ioctl:
> >
> > long ioctl_syscall(int fd, long syscall, long args[6]);
> >
> > This is simply equivalent to:
> >
> > syscall(syscall, args[0], args[1], args[2], args[3], args[4],
> > args[5], args[6]);
>
> Wait, why? Why do you want to do something like this, what problem are
> you trying to solve that you feel that something like this is the
> solution? Let's step back and see if there isn't a better way to do
> this.
>
You are correct that there is a different problem that I really want to
solve.
Here is the different problem: I want to have a new device (let's call
it `/dev/async_syscall`), with root:root owner and 0600 permissions.
When the user opens the device, the returned file descriptor can be used
to submit an async syscall request using the following ioctl:
/* Fixed-size types to avoid a 32-bit compat layer */
struct linux_async_syscall {
__u64 syscall;
__u64 args[6];
__u64 user1;
__u64 user2;
};
/* arguments is really a struct linux_async_syscall * */
/* n_syscalls is really a size_t */
int ioctl(int fd, LINUX_ASYNC_SYSCALL, __u64 n_syscalls,
__u64 arguments, __u64 num_succeed);
Here `arguments` is an array of `struct linux_async_syscall` with
size `n_syscalls`, and `num_succeeded` is a pointer to an `int` that
receives the number of successfully submitted system calls.
In the kernel, this does the following:
1. Check that the parameters make sense
2. Copy them into kernel memory, and place the memory somewhere where it
will be freed if the process terminates.
3. For each `struct linux_async_syscall` passed:
1. Run seccomp filters to ensure that the process can actually make
the syscall.
2. Check the syscall against a whitelist of system calls that can be
made asynchronously.
4. Call the in-kernel implementation of clone(), creating a new
kernel thread.
5. In the parent, return success if and only if the thread creation was
successfull.
6. In the child, for each `struct linux_async_syscall` passed, invoke
the system call, as if from userspace. Upon return, post a message
to the file descriptor, which the userspace process can then
retrieve with read(2).
I am sure there are more optimizations to be made, or possibly an
entirely different and superior approach.
> > and indeed I want it to behave *identically* to that. That means that
> > ptracers are notified about the syscall (and given the opportunity to
> > update its arguments), and that seccomp_bpf filters are applied.
> > Furthermore, it means that all arguments to the syscall need full
> > validation, as if they came from userspace (because they do).
> >
> > Is there an in-kernel API that allows one to invoke an arbitrary syscall
> > with arguments AND proper ptrace/seccomp_bpf filtering? If not, how
> > difficult would it be to create one?
>
> Wouldn't creating such an interface be more work than just using the
> correct user/kernel interface in the first place? :)
>
Yes, it would. :)
However, the ioctl I actually want to implement (see above) does the
system call asynchronously. That isn’t possible using the existing
APIs.
>
> Again, what is the problem you are trying to solve here.
>
See above :) Basically, I am trying to improve performance and reduce
complexity of programs that need to do a lot of buffered file I/O.
>
> thanks,
>
> greg k-h
>
Thank you, Greg!
Demi
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
why iowrite32_rep() doesn't work, I have to use the iowrite32() with a loop
Hello All:
I am writing a driver, I need to write a series of values into the
registers. The old code use the writel_relaxed() to avoid flushing cache
between echo of register. I want to use the recommended way of the io
operations, so I choose the iowrite32()_req(), but I found what it wrote
nothing, I read it at once after a memory barrier, there is no contents
there. But it I use the iowrite32() with a loop, it works well and the
registers of the device is configured. What make this problem?
The io memory is assigned with devm_ioremap_resource().
void mpp_dev_write_seq(struct rockchip_mpp_dev *mpp_dev, unsigned long
offset,
void *buffer, unsigned long count)
{
int i;
#if 1
for (i = 0; i < count; i++) {
u32 *cur = (u32 *)buffer;
u32 pos = offset + i * 4;
cur += i;
mpp_debug(DEBUG_SET_REG, "write reg[%03d]: %08x\n",
pos, *cur);
iowrite32(*cur, mpp_dev->reg_base + pos);
}
#else
iowrite32_rep(mpp_dev->reg_base + offset, buffer, count);
mb();
for (i = 0; i < count; i++) {
u32 cur = 0;
u32 pos = offset / 4 + i;
cur = ioread32(mpp_dev->reg_base + pos * 4);
pr_info("get reg[%03d]: %08x\n", pos, cur);
}
#endif
}
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Is there a to prevent a file descriptor being closed
Hello I am writing a driver to operation with the dma-buf, a problem I meet is that a dma-buf maybe closed by the other driver or userspace application, then the same number of the file descriptor will be assigned with the other thing, its private data is different. I watch what the drm system do. The drm system doesn't use the file descriptor but the its private data (from dma_buf_get()) to check whether it is the same buffer. Is there a reference in the file descriptor? And is there a way to increase the reference to a file descriptor. I have designed a way to track the usage of the dma-buf of my driver, there is not a problem for the driver to release them. But I just want the new dma-buf is assigned with new file descriptor number, not re-use the closed one. Thank you. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: git pull
Linus Torvalds writes: > On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding wrote: >> >> Linus do you care what protocol? I'm patching Documentation and since >> the point is creating pull requests for you 'some people' don't matter. > > I actually tend to prefer the regular git:// protocol and signed tags. > > It's true that https should have the proper certificate and perhaps > help with DNS spoofing, but I'm not convinced that git won't just > accept self-signed random certs, and I basically don't think we should > trust that. git does not accept self-signed certs by default, at least in recent versions. Though you can do a trust-on-first-use type thing, by downloading the cert and telling git where to find it. So https does provide additional security vs git:// IMHO. There is some verification of the server and your data is encrypted on the wire. It's not like it would be trivial to MITM a git fetch to insert a malicious Makefile change, but it's also not *hard*. > In contrast, using ssh I would actually trust, but it's not convenient > and involves people sending things that aren't necessarily publicly > available. > > So instead, I prefer just using git:// and not trying to fool people > into thinking the protocol is secure - the security should come from > the signed tag. That's true, but only when you're pulling a signed tag, which for most people is not the common case. ... > That said, I actually would prefer even kernel.org repositories to > just send pull requests with signed tags, despite the protocol itself > being secure for that (and only that). Which you mention here. cheers ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: why iowrite32_rep() doesn't work, I have to use the iowrite32() with a loop
On Thu, Nov 16, 2017 at 12:12 PM, ayaka wrote:
> #if 1
> for (i = 0; i < count; i++) {
> u32 *cur = (u32 *)buffer;
> u32 pos = offset + i * 4;
>
> cur += i;
> mpp_debug(DEBUG_SET_REG, "write reg[%03d]: %08x\n",
> pos, *cur);
> iowrite32(*cur, mpp_dev->reg_base + pos);
> }
> #else
> iowrite32_rep(mpp_dev->reg_base + offset, buffer, count);
> mb();
> for (i = 0; i < count; i++) {
> u32 cur = 0;
> u32 pos = offset / 4 + i;
>
> cur = ioread32(mpp_dev->reg_base + pos * 4);
> pr_info("get reg[%03d]: %08x\n", pos, cur);
> }
> #endif
The loop with iowrite32 writes consecutive u32 words from buffer
to consecutive IO memory locations. But iowrite32_rep writes
consecutive u32 words from buffer to the same IO memory location.
So they do different things when count > 1.
--
Thanks.
-- Max
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: git pull
[...] > > An example pull request of mine might look like: > Char/Misc patches for 4.15-rc1 > > Here is the big char/misc patch set for the 4.15-rc1 merge > window. Contained in here is the normal set of new functions > added to all of these crazy drivers, as well as the following > brand new subsystems: > - time_travel_controller: Finally a set of drivers for > the latest time travel bus architecture that provides > i/o to the CPU before it asked for it, allowing > uninterrupted processing > - relativity_shifters: due to the affect that the > time_travel_controllers have on the overall system, > there was a need for a new set of relativity shifter > drivers to accommodate the newly formed black holes > that would threaten to suck CPUs into them. This > subsystem handles this in a way to successfully > neutralize the problems. There is a Kconfig option to > force these to be enabled when needed, so problems > should not occur. > > All of these patches have been successfully tested in the latest > linux-next releases, and the original problems that it found > have all been resolved (apologies to anyone living near Canberra > for the lack of the Kconfig options in the earlier versions of > the linux-next tree creations.) > > Signed-off-by: Your-name-here > > > The tag message format is just like a git commit id. One line at the > top for a "summary subject" and be sure to sign-off at the bottom. I don't add my s-o-b to signed tags for pull requests, but perhaps I should. However, I think most maintainers don't use it, and neither does it seems like Linus is preserving the tag when he does the pull. [...] Kind regards Uffe ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: My first patch - patch for adl_pci9118.c
On Sat, Nov 18, 2017 at 01:07:30PM +0100, Fabian Baumanis wrote:
> Hi there,
>
> this morning i created my first patch for the Linux kernel.
> It fixes a style issue which was reported by using checkpatch.pl on
> drivers/staging/comedi/drivers/adl_pci9118.c
>
> Although it's a very small patch, i hope this is useful.
> My question now is: how can i submit the patch to the developers?
Please read Documentation/SubmittingPatches for the steps for how to
submit a patch.
> Best regards and have a nice weekend,
> Fabian
>
> 949,950c949
> < if ((cmd->flags & CMDF_WAKE_EOS) &&
> < (cmd->scan_end_arg == 1)) {
> ---
> > if cmd->flags & CMDF_WAKE_EOS && cmd->scan_end_arg == 1 {
Have you built the code with your change applied? Always do that first
:)
thanks,
greg k-h
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
My first patch - patch for adl_pci9118.c
Hi there,
this morning i created my first patch for the Linux kernel.
It fixes a style issue which was reported by using checkpatch.pl on
drivers/staging/comedi/drivers/adl_pci9118.c
Although it's a very small patch, i hope this is useful.
My question now is: how can i submit the patch to the developers?
Best regards and have a nice weekend,
Fabian
949,950c949
< if ((cmd->flags & CMDF_WAKE_EOS) &&
< (cmd->scan_end_arg == 1)) {
---
> if cmd->flags & CMDF_WAKE_EOS && cmd->scan_end_arg == 1 {
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
