On Wed, 3 Dec 2014 11:41:44 +0100
Richard Cochran wrote:
> On Wed, Dec 03, 2014 at 09:17:37AM +0100, Richard Weinberger wrote:
> > Come on guys, get a cup of coffee and relax a bit...
>
> I am relaxed, especially after I had a good laugh reading this:
>
>On a less related note, I hope you w
On Wed, Dec 3, 2014 at 9:41 PM, Richard Cochran
wrote:
> In any case, I find it hard to believe that the traditional method is
> really so bad. The explanation of why this new way is needed boils
> down to: "unix programming is so hard to get right."
Surely, this can be said about any new featur
On Wed, Dec 03, 2014 at 09:17:37AM +0100, Richard Weinberger wrote:
> Come on guys, get a cup of coffee and relax a bit...
I am relaxed, especially after I had a good laugh reading this:
On a less related note, I hope you will agree that the simpler
mechanism for this very in-demand feature
On Wed, Dec 3, 2014 at 9:08 AM, Richard Cochran
wrote:
> On Tue, Dec 02, 2014 at 10:50:46PM -0800, Eric Dumazet wrote:
>> I think I will ignore your future mails.
>
> And I won't have time to read them either, because I will be too busy
> passing fds to my two collies.
Come on guys, get a cup of
On Tue, Dec 02, 2014 at 10:50:46PM -0800, Eric Dumazet wrote:
> I think I will ignore your future mails.
And I won't have time to read them either, because I will be too busy
passing fds to my two collies.
Cheers,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Wed, 2014-12-03 at 13:22 +1100, Alex Dubov wrote:
> Yours is the first insightful message in this thread. Some of the
> other commenters exhibited an unfortunate lack of understanding,
> regarding what signals are and what they can be useful for.
Oh nice.
I think I will ignore your future mai
On Wed, 2014-12-03 at 13:11 +1100, Alex Dubov wrote:
> Kindly enlighten me, how are you going to use any file descriptor in a
> 128 threads program in a scalable way (socket and all)? How this
> approach will be different when using signalfd()?
Thats the point : use one different channel (AF_UNIX
On Wed, Dec 3, 2014 at 2:40 PM, Al Viro wrote:
> On Wed, Dec 03, 2014 at 01:22:33PM +1100, Alex Dubov wrote:
>
>> On a less related note, I hope you will agree that the simpler
>> mechanism for this very in-demand feature is long overdue on Linux
>> (every man and his dog are passing fds around th
On Wed, Dec 03, 2014 at 01:22:33PM +1100, Alex Dubov wrote:
> On a less related note, I hope you will agree that the simpler
> mechanism for this very in-demand feature is long overdue on Linux
> (every man and his dog are passing fds around these days).
... and I'm less than sure that it's a goo
On Wed, Dec 3, 2014 at 4:00 AM, Al Viro wrote:
> On Tue, Dec 02, 2014 at 03:35:18PM +1100, Alex Dubov wrote:
>> +
>> + if (rc < 0)
>> + __close_fd(dst_files, s_info.si_int);
>
> Oh, lovely... And we are guaranteed that it still the same file, because...?
>
> Not to mention anythin
On Wed, Dec 3, 2014 at 3:42 AM, Eric Dumazet wrote:
> On Wed, 2014-12-03 at 03:23 +1100, Alex Dubov wrote:
>
> Tell me how a 128 threads program can use this new mechanism in a
> scalable way.
>
> One signal per thread ?
What for?
Kernel will deliver the signal only to the thread/threads which h
On Tue, Dec 02, 2014 at 03:35:18PM +1100, Alex Dubov wrote:
> + dst_files = get_files_struct(dst_task);
> + if (!dst_files) {
> + rc = -EMFILE;
> + goto out_put_dst_task;
> + }
> +
> + if (!lock_task_sighand(dst_task, &flags)) {
> + rc = -EMFILE;
On Wed, 2014-12-03 at 03:23 +1100, Alex Dubov wrote:
> Same as SIGKILL. And yet, our machines are still working fine.
>
> If process A has sufficient capability to send signals to process B,
> then process B is already at its mercy, fds or not fds.
Tell me how a 128 threads program can use this
On Wed, Dec 3, 2014 at 2:33 AM, Eric Dumazet wrote:
> On Wed, 2014-12-03 at 01:47 +1100, Alex Dubov wrote:
>> > User A can send fd(s) to processes belonging to user B, even if user B
>> > does (probably) not want this to happen ?
>>
>> 1. Process A must have sufficient permissions to signal proces
On Wed, 2014-12-03 at 01:47 +1100, Alex Dubov wrote:
> > User A can send fd(s) to processes belonging to user B, even if user B
> > does (probably) not want this to happen ?
>
> 1. Process A must have sufficient permissions to signal process B.
> This will only happen if process A belongs to the s
> User A can send fd(s) to processes belonging to user B, even if user B
> does (probably) not want this to happen ?
1. Process A must have sufficient permissions to signal process B.
This will only happen if process A belongs to the same user as process
B or has elevated capabilities, which can n
On Tue, 2014-12-02 at 15:35 +1100, Alex Dubov wrote:
> Present patch introduces exceptionally easy to use, low latency and low
> overhead mechanism for transferring file descriptors between cooperating
> processes:
>
> int sendfd(pid_t pid, int sig, int fd)
>
> Given a target process pid, the
Present patch introduces exceptionally easy to use, low latency and low
overhead mechanism for transferring file descriptors between cooperating
processes:
int sendfd(pid_t pid, int sig, int fd)
Given a target process pid, the sendfd() syscall will create a duplicate
file descriptor in a targ
18 matches
Mail list logo
