* Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)
From: Paul E. McKenney @ 2018-04-02 15:27 UTC (permalink / raw)
To: Christopher Lameter
Cc: Alan Cox, Mathieu Desnoyers, Peter Zijlstra, Boqun Feng,
Andy Lutomirski, Dave Watson, linux-kernel, linux-api,
Paul Turner, Andrew Morton, Russell King, Thomas Gleixner,
Ingo Molnar, H . Peter Anvin, Andrew Hunter, Andi Kleen,
Ben Maurer, Steven Rostedt, Josh Triplett, Linus Torvalds,
Catalin Marinas
In-Reply-To: <alpine.DEB.2.20.1804021000290.23911@nuc-kabylake>
On Mon, Apr 02, 2018 at 10:03:58AM -0500, Christopher Lameter wrote:
> On Sun, 1 Apr 2018, Alan Cox wrote:
>
> > > Restartable sequences are atomic with respect to preemption
> > > (making it atomic with respect to other threads running on the
> > > same CPU), as well as signal delivery (user-space execution
> > > contexts nested over the same thread).
> >
> > CPU generally means 'big lump with legs on it'. You are not atomic to the
> > same CPU, because that CPU may have 30+ cores with 8 threads per core.
> >
> > It could do with some better terminology (hardware thread, CPU context ?)
>
> Well we call it a "CPU" in the scheduler context I think. We could use
> better terminology throughout the kernel tools and source.
Agreed, it has been "CPU" for "single hardware thread" for a very long
time. People tend to use "core" for "group of hardware threads" and
"socket" for "big lump with legs on it".
> Hardware Execution Context?
Should be even more fun when non-CPU hardware execution contexts show
up in force within each core. ;-)
But the terminology in place for non-CPU hardware execution contexts
should be able to survive that event.
> > > In a typical usage scenario, the thread registering the rseq
> > > structure will be performing loads and stores from/to that
> > > structure. It is however also allowed to read that structure
> > > from other threads. The rseq field updates performed by the
> > > kernel provide relaxed atomicity semantics, which guarantee
> > > that other threads performing relaxed atomic reads of the cpu
> > > number cache will always observe a consistent value.
> >
> > So what happens to your API if the kernel atomics get improved ? You are
> > effectively exporting rseq behaviour from private to public.
>
> There is already a pretty complex coherency model guiding kernel atomics.
> Improvements/changes to that are difficult and the effect will ripple
> throughout the kernel. So I would suggest that these areas of the kernel
> are pretty "petrified" (or written in stone).
I suspect that there are much more pressing areas of confusion in any
case!
Thanx, Paul
^ permalink raw reply
* Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)
From: Christopher Lameter @ 2018-04-02 15:03 UTC (permalink / raw)
To: Alan Cox
Cc: Mathieu Desnoyers, Peter Zijlstra, Paul E . McKenney, Boqun Feng,
Andy Lutomirski, Dave Watson, linux-kernel, linux-api,
Paul Turner, Andrew Morton, Russell King, Thomas Gleixner,
Ingo Molnar, H . Peter Anvin, Andrew Hunter, Andi Kleen,
Ben Maurer, Steven Rostedt, Josh Triplett, Linus Torvalds,
Catalin Marinas <catalin.>
In-Reply-To: <20180401171356.085a2a33@alans-desktop>
On Sun, 1 Apr 2018, Alan Cox wrote:
> > Restartable sequences are atomic with respect to preemption
> > (making it atomic with respect to other threads running on the
> > same CPU), as well as signal delivery (user-space execution
> > contexts nested over the same thread).
>
> CPU generally means 'big lump with legs on it'. You are not atomic to the
> same CPU, because that CPU may have 30+ cores with 8 threads per core.
>
> It could do with some better terminology (hardware thread, CPU context ?)
Well we call it a "CPU" in the scheduler context I think. We could use
better terminology throughout the kernel tools and source.
Hardware Execution Context?
> > In a typical usage scenario, the thread registering the rseq
> > structure will be performing loads and stores from/to that
> > structure. It is however also allowed to read that structure
> > from other threads. The rseq field updates performed by the
> > kernel provide relaxed atomicity semantics, which guarantee
> > that other threads performing relaxed atomic reads of the cpu
> > number cache will always observe a consistent value.
>
> So what happens to your API if the kernel atomics get improved ? You are
> effectively exporting rseq behaviour from private to public.
There is already a pretty complex coherency model guiding kernel atomics.
Improvements/changes to that are difficult and the effect will ripple
throughout the kernel. So I would suggest that these areas of the kernel
are pretty "petrified" (or written in stone).
^ permalink raw reply
* Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces
From: Manfred Spraul @ 2018-04-02 11:11 UTC (permalink / raw)
To: Davidlohr Bueso, Eric W. Biederman
Cc: Linux Containers, linux-kernel, linux-api, khlebnikov,
prakash.sangappa, luto, akpm, oleg, serge.hallyn, esyr, jannh,
linux-security-module, Pavel Emelyanov, Nagarathnam Muthusamy
In-Reply-To: <20180330190951.nfcdwuzp42bl2lfy@linux-n805>
Hi,
On 03/30/2018 09:09 PM, Davidlohr Bueso wrote:
> On Wed, 28 Mar 2018, Davidlohr Bueso wrote:
>
>> On Fri, 23 Mar 2018, Eric W. Biederman wrote:
>>
>>> Today the last process to update a semaphore is remembered and
>>> reported in the pid namespace of that process. If there are processes
>>> in any other pid namespace querying that process id with GETPID the
>>> result will be unusable nonsense as it does not make any
>>> sense in your own pid namespace.
>>
>> Yeah that sounds pretty wrong.
>>
>>>
>>> Due to ipc_update_pid I don't think you will be able to get System V
>>> ipc semaphores into a troublesome cache line ping-pong. Using struct
>>> pids from separate process are not a problem because they do not share
>>> a cache line. Using struct pid from different threads of the same
>>> process are unlikely to be a problem as the reference count update
>>> can be avoided.
>>>
>>> Further linux futexes are a much better tool for the job of mutual
>>> exclusion between processes than System V semaphores. So I expect
>>> programs that are performance limited by their interprocess mutual
>>> exclusion primitive will be using futexes.
>>
The performance of sysv sem and futexes for the contended case is more
or less identical, it depends on the CONFIG_ options what is faster.
And this is obvious, both primitives must do the same tasks:
sleep:
- lookup a kernel pointer from a user space reference
- acquire a lock, do some housekeeping, unlock and sleep
wakeup:
- lookup a kernel pointer from a user space reference
- acquire a lock, do some housekeeping, especially unlink the to be
woken up task, unlock and wakeup
The woken up task has nothing to do, it returns immediately to user space.
IIRC for the uncontended case, sysvsem was at ~300 cpu cycles, but that
number is a few years old, and I don't know what is the impact of spectre.
The futex code is obviously faster.
But I don't know which real-world applications do their own
optimizations for the uncontended case before using sysvsem.
Thus the only "real" challenge is to minimize cache line trashing.
>> You would be wrong. There are plenty of real workloads out there
>> that do not use futexes and are care about performance; in the end
>> futexes are only good for the uncontended cases, it can also
>> destroy numa boxes if you consider the global hash table. Experience
>> as shown me that sysvipc sems are quite still used.
>>
>>>
>>> So while it is possible that enhancing the storage of the last
>>> rocess of a System V semaphore from an integer to a struct pid
>>> will cause a performance regression because of the effect
>>> of frequently updating the pid reference count. I don't expect
>>> that to happen in practice.
>>
>> How's that? Now thanks to ipc_update_pid() for each semop the user
>> passes, perform_atomic_semop() will do two atomic updates for the
>> cases where there are multiple processes updating the sem. This is
>> not uncommon.
>>
>> Could you please provide some numbers.
>
[...]
> So at least for a large box this patch hurts the cases where there is low
> to medium cpu usage (no more than ~8 processes on a 40 core box) in a non
> trivial way. For more processes it doesn't matter. We can confirm that
> the
> case for threads is irrelevant. While I'm not happy about the 30%
> regression
> I guess we can live with this.
>
> Manfred, any thoughts?
>
Bugfixing has always first priority, and a 30% regression in one
microbenchmark doesn't seem to be that bad.
Thus I would propose that we fix SEMPID first, and _if_ someone notices
a noticeable regression, then we must improve the code.
--
Manfred
^ permalink raw reply
* Re: [PATCH v4 04/24] fpga: add device feature list support
From: Wu Hao @ 2018-04-02 4:22 UTC (permalink / raw)
To: Alan Tull
Cc: Moritz Fischer, linux-fpga, linux-kernel, linux-api, Kang, Luwei,
Zhang, Yi Z, Tim Whisonant, Enno Luebbers, Shiva Rao,
Christopher Rauer, Xiao Guangrong
In-Reply-To: <CANk1AXQVMCySDjG1_aCxyot612Xg+Vf=vLqk3QY2wpruOAjfpw@mail.gmail.com>
On Thu, Mar 29, 2018 at 04:57:22PM -0500, Alan Tull wrote:
> On Mon, Mar 26, 2018 at 9:35 PM, Wu Hao <hao.wu@intel.com> wrote:
>
> Hi Hao,
>
> Currently there is one set of functions that handles port enable,
> disable, and reset and it's in dfl.c and dfl.h, so that's not in any
> driver module that can be switched out if necessary for a different
> implementation of the port. Finding a way for this patchset to be
> structured for DFL to control what low level manager/port drivers are
> used is the current challenge that I've got a lot of my attention on.
>
> Thanks for the explanations on how virtualization affects how this can
> be implemented.
>
> > On Mon, Mar 26, 2018 at 12:21:23PM -0500, Alan Tull wrote:
> >> On Thu, Mar 22, 2018 at 11:33 PM, Wu Hao <hao.wu@intel.com> wrote:
> >>
> >> >> > +
> >> >> > +/*
> >> >> > + * This function resets the FPGA Port and its accelerator (AFU) by function
> >> >> > + * __fpga_port_disable and __fpga_port_enable (set port soft reset bit and
> >> >> > + * then clear it). Userspace can do Port reset at any time, e.g during DMA
> >> >> > + * or Partial Reconfiguration. But it should never cause any system level
> >> >> > + * issue, only functional failure (e.g DMA or PR operation failure) and be
> >> >> > + * recoverable from the failure.
> >> >> > + *
> >> >> > + * Note: the accelerator (AFU) is not accessible when its port is in reset
> >> >> > + * (disabled). Any attempts on MMIO access to AFU while in reset, will
> >> >> > + * result errors reported via port error reporting sub feature (if present).
> >> >> > + */
> >> >> > +static inline int __fpga_port_reset(struct platform_device *pdev)
> >> >> > +{
> >> >> > + int ret;
> >> >> > +
> >> >> > + ret = __fpga_port_disable(pdev);
> >> >> > + if (ret)
> >> >> > + return ret;
> >> >> > +
> >> >> > + __fpga_port_enable(pdev);
> >> >> > +
> >> >> > + return 0;
> >> >> > +}
> >> >> > +
> >> >> > +static inline int fpga_port_reset(struct platform_device *pdev)
> >> >> > +{
> >> >> > + struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> >> >> > + int ret;
> >> >> > +
> >> >> > + mutex_lock(&pdata->lock);
> >> >> > + ret = __fpga_port_reset(pdev);
> >> >> > + mutex_unlock(&pdata->lock);
> >> >> > +
> >> >> > + return ret;
> >> >> > +}
> >> >>
> >> >> I'm still scratching my head about how the enumeration code also has
> >> >> code that handles resetting the PL in a FPGA region and
> >> >> enabling/disabling the bridge. We've discussed this before [1] and I
> >> >> know you've looked into it, I'm still trying to figure out how this
> >> >> can be made modular, so when someone needs to support a different port
> >> >> in the future, it isn't a complete rewrite.
> >> >>
> >> >> Speaking of resets, one way forward would be to create a reset
> >> >> controller for the port (and if possible move the port code to the
> >> >> bridge platform driver). The current linux-next repo adds support for
> >> >> reset lookups, so that reset controllers are supported for non-DT
> >> >> platforms [2].
> >> >>
> >> >> So the bridge driver would implement the enable/disable functions and
> >> >> create a reset controller, the fpga-region (or whoever else needs it)
> >> >> could look the reset controller and use the reset. By using the
> >> >> kernel reset framework, we don't have to have that piece of code
> >> >> shared around by having a reset function in a .h file. And it avoids
> >> >> adding extra dependencies between modules. Also, where necessary, I'd
> >> >> rather add functionality to the existing bridge/mgr/region frameworks,
> >> >> adding common interfaces at that level to allow reuse (like adding
> >> >> status to fpga-mgr). Ideally, this DFL framework would sit on top of
> >> >> mgr and bridge and allow those to be swapped out for reuse of the DFL
> >> >> framework on other devices. Also it will save future headaches as mgr
> >> >> or port implementations evolve.
> >> >
> >> > Thanks a lot for the suggestion. I really really appreciate this.
> >>
> >> Yes, this is a good discussion, thanks.
> >>
> >> >
> >> > Actually if we consider the virutalization case as I mentioned in [1] below,
> >> > that means AFU and its Port will be turned into a PCI VF and assigned (passed
> >> > through) to a virtual machine. There is no FME block on that PCI VF device,
> >> > (the FME is always kept in PCI PF device in the host) and currently the bridge
> >> > is created by FME module for PR functionatily. So in the guest virtual machine,
> >> > nobody creates the reset controller actually.
> >> >
> >> > As I mentioned in [1], one possible method is, put these port reset functions to
> >> > AFU (Port) module, and share those functions with FME bridge module.
> >>
> >> Yes, the port reset functions could move into an AFU driver, and then
> >> also the AFU driver could also create a reset controller and register
> >> a lookup [2] for the reset. That would be just a few lines of code.
> >> The reset controller would control enabling/disabling the port. The
> >> bridge driver could get the reset controller to use during FPGA
> >> programming. That is instead of sharing a reset function with the
> >> bridge driver. It decouples the FPGA bridge driver and simplifies it
> >> to be something that just needs to control a reset instead of needing
> >> to include a specific .h file that makes a port reset function
> >> available.
> >
> > Hi Alan
> >
> > Thanks a lot for the feedback. :)
> >
> > The major concern here is, for virtualization case, after we enable the SRIOV
> > to create VFs, AFUs(and ports) are turned into VFs from PF. Once AFUs are moved
> > from PF to VFs, then we should remove all related user interfaces exported by
> > the afu platform device under PF by unregistering these platform devices from
> > the system. So in this case the reset controller created by the AFU platform
> > driver, should be removed when the AFU platform devices are deleted from the
> > system in this case, but we still have FME and FME bridge present on PF, then
> > FME bridge can't find the reset controller any longer to do port enable/disable.
>
> OK
>
> >
> > Sorry, I found my previous description is not accurate.
> >
> > VFs could be passed through to a virtual machine, if we let AFU/Port create
> > reset controller, then the reset controllers are created in the virtual machine.
> > And FME is always in PF in the host, so FME bridge in host have no access to the
> > reset controllers in the virtual machine.
>
> Thanks for the explanation. Does the current implementation allows
> the port's PORT_CTRL_SFTRST reset bit to be controlled by PF and VF at
> the same time?
Yes, it allows it to be accessed by PF and VF at the same time, only for Port
Registers, not for AFU registers (any access will cause errors reported by HW).
> Or is the idea that the VF has to be given up in order to allow the FME PF to
> be able to reprogram?
Without any notification mechanism between PF and VFs, the safe way of doing the
PR to AFUs (accelerators) on VFs is, 1) hot-unplug the AFU (VF) from the VM,
2) turn the AFU back to PF from VF, 3) PR to the AFU on PF, 4) turn that AFU to
VF again, 5) hot-plug the AFU (VF) to target VM again. We tested this flow, it
works and doesn't need to shutdown the VM. But once we have implemented some
methods to notification between PF and VFs, we don't have to do these steps.
> After the AFU and port is turned into a VF, is the port's memory range is
> mapped in both the PF and the VF?
Yes.
>
> >
> >>
> >> > I think
> >> > that will make the code in the common DFL framework a little more clean,
> >>
> >> Yes, IIUC that may also make it easier as the port/AFU gets added
> >> functionality that is intended to be controlled by the VF anyway
> >> (while the only port-related thing that is needed by the FME is port
> >> enable/disable).
> >>
> >> > but it
> >> > will introduce some module dependency here for sure, (e.g FME modules can't
> >> > finish PR without AFU (Port) Module loaded).
> >>
> >> That sounds like an OK type of dependency, i.e. if the modules are not
> >> all loaded, it doesn't work. :-)
> >
> > Find a reset controller by lookup, if not found, return error code. It seems
> > not a really hard module dependency between port/afu and FME bridge modules.
>
> That was what I was hoping would work here. But if the module isn't
> loaded because it failed due to the reset controller in the AFU driver
> went away, then, yes, that won't work.
>
> > But if in FME bridge, it uses functions exposed by port/afu module, that's a
> > hard dependency. : )
>
> Yes I'm trying to find ways to get away from that kind of hard
> dependency. So when someone uses this with a different port, it won't
> be a huge rewrite of dfl.c and dfl.h. I understand that the port is
> used by both the AFU and the PR code, that's why it's in a file that
> is included by both of them. That's going to be a problem as soon as
> this is used with a different port.
or we could add some callbacks, and let port driver register its own function
for enable/disable operation? But then dfl.c / dfl.h will still see some common
port code there.
>
> >
> > I can try to move related code to afu/port driver instead in the next version
> > for sure, but I can't create the reset controller per the reason above. Please
> > let me know if more thoughts on this. : )
>
> Maybe that is the way forward. I'm still thinking about this. So the
> DFL will create a AFU driver that includes the port. If someone
> implements a different port, there would be a different id to cause
> that AFU driver to be loaded instead. It seems a shame that more of
> the AFU code couldn't be reused. That was the original idea of
> fpga-bridge. Unfortunately it seems that the bridge is needed by both
> the VF and PF so it's complicated by that.
>
> >
> >>
> >> > But anyway it may be still
> >> > acceptable for users as all these modules could be loaded automatically. How do
> >> > you think? :)
> >>
> >> The other thing I want to get right now is if there is a different
> >> AFU/port that needs a different driver. Can the DFL be changed to
> >> specify what AFU/port to load? I really really want to avoid large
> >> code rewrites in the future that we can anticipate now. Such as
> >> someone implements their own static image, it has DFL, but the port is
> >> somewhat different. Instead of seeing features as just something that
> >> gets added, the DFL also specifies what port driver and mgr driver to
> >> load. The stuff we discussed above is a good step towards that, but
> >> not all of it.
> >
> > I'm not sure if any vendor
>
> Since this is open source, it's important to remember that vendors
> aren't the only ones driving development of Linux. Any user of FPGA
> under Linux can (and has) come along and add to this subsystem. This
> code should not discourage that.
Agree.
>
> > wants to create a totally different port here, if
> > yes, then it could have a different feature id in Device Feature Header (DFH).
> > I think it's possible to use that feature id to decide which driver to load
> > (or which platform device to create).
>
> I think it's what we need.
Yes.
>
> > But vendors don't have to do that, as it
> > could reuse current port driver and private features added already, or even
> > add some new vendor specific private feature under the port to save cost.
>
> They would have to implement a static image with port registers that
> function the same way for at least port enable/disable/reset. If they
> need to tweak the driver implementation for their hardware then that's
> not possible or it's ugly at least.
Agree, in that case, it's better to use a new feature id with a different
port implementation.
> This is also the case if you have some newer version of you port while
> keeping legacy support for your original port.
In Device Feature Header, there is a field to indicate the revision of
this Port (private feature has revision bit in DFH too). But we should
not use this field to indicate a totally different implementation.
>
> I understand that virtualization is making this hard. Thanks for
> thinking about how this can move forward on this issue.
Yes, I will try to move the actual port related code into AFU/port driver
in the next version, thanks for the comments and suggestions.
Thanks
Hao
>
> Alan
>
> >
> > Thanks
> > Hao
> >
> >>
> >> Alan
> >>
> >> >
> >> > Thanks
> >> > Hao
> >> >
> >> >
> >> >>
> >> >> Alan
> >> >>
> >> >> [1] https://lkml.org/lkml/2017/12/22/398
> >> >> [2] https://patchwork.kernel.org/patch/10247475/
^ permalink raw reply
* Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing
From: Tycho Andersen @ 2018-04-02 0:39 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Andy Lutomirski, LKML, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Casey Schaufler, Daniel Borkmann,
David Drysdale, David S . Miller, Eric W . Biederman,
James Morris, Jann Horn, Jonathan Corbet, Michael Kerrisk,
Kees Cook, Paul Moore, Sargun Dhillon, Serge E . Hallyn,
Shuah Khan, Tejun Heo, Thomas Graf, Will Drewry
In-Reply-To: <0f355079-7ee2-c06a-2d47-a7a2fa6d98fe@digikod.net>
Hi Mickaël,
On Mon, Apr 02, 2018 at 12:04:36AM +0200, Mickaël Salaün wrote:
> >> vDSO is a code mapped for all processes. As you said, these processes
> >> may use it or not. What I was thinking about is to use the same concept,
> >> i.e. map a "shim" code into each processes pertaining to a particular
> >> hierarchy (the same way seccomp filters are inherited across processes).
> >> With a seccomp filter matching some syscall (e.g. mount, open), it is
> >> possible to jump back to the shim code thanks to SECCOMP_RET_TRAP. This
> >> shim code should then be able to emulate/patch what is needed, even
> >> faking a file opening by receiving a file descriptor through a UNIX
> >> socket. As did the Chrome sandbox, the seccomp filter may look at the
> >> calling address to allow the shim code to call syscalls without being
> >> catched, if needed. However, relying on SIGSYS may not fit with
> >> arbitrary code. Using a new SECCOMP_RET_EMULATE (?) may be used to jump
> >> to a specific process address, to emulate the syscall in an easier way
> >> than only relying on a {c,e}BPF program.
> >>
> >
> > This could indeed be done, but I think that Tycho's approach is much
> > cleaner and probably faster.
> >
>
> I like it too but how does this handle file descriptors?
I think it could be done fairly simply, the most complicated part is
probably designing an API that doesn't suck. But the basic idea would
be:
struct seccomp_notif_resp {
__u64 id;
__s32 error;
__s64 val;
__s32 fd;
};
if the handler responds with fd >= 0, we grab the tracer's fd,
duplicate it, and install it somewhere in the tracee's fd table. Since
things like socket() will want to return the fd number as its
installed and the handler doesn't know that, we'll probably want some
way to indicate that the kernel should return this value. We could
either mandate that if fd >= 0, that's the value that will be returned
from the syscall, or add another flag that says "no, install the fd,
but really return what's in val instead).
I guess we can't mandate that we return fd, because e.g. netlink
sockets can sometimes return fds as part of the netlink messages, and
not as the return value from the syscall.
Tycho
^ permalink raw reply
* Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions
From: Mickaël Salaün @ 2018-04-01 22:48 UTC (permalink / raw)
To: Andy Lutomirski
Cc: LKML, Alexei Starovoitov, Arnaldo Carvalho de Melo,
Casey Schaufler, Daniel Borkmann, David Drysdale,
David S . Miller, Eric W . Biederman, James Morris, Jann Horn,
Jonathan Corbet, Michael Kerrisk, Kees Cook, Paul Moore,
Sargun Dhillon, Serge E . Hallyn, Shuah Khan, Tejun Heo,
Thomas Graf, Tycho Andersen, Will Drewry, Kernel
In-Reply-To: <679089bb-c0ac-ff68-71b1-1813d66c6aa7@digikod.net>
[-- Attachment #1.1: Type: text/plain, Size: 3058 bytes --]
On 03/06/2018 11:28 PM, Mickaël Salaün wrote:
>
> On 28/02/2018 01:09, Andy Lutomirski wrote:
>> On Wed, Feb 28, 2018 at 12:00 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>>
>>> On 28/02/2018 00:23, Andy Lutomirski wrote:
>>>> On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>>> On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün <mic@digikod.net> wrote:
>>>>>>
>>>>>
>>>>> I think you're wrong here. Any sane container trying to use Landlock
>>>>> like this would also create a PID namespace. Problem solved. I still
>>>>> think you should drop this patch.
>>>
>>> Containers is one use case, another is build-in sandboxing (e.g. for web
>>> browser…) and another one is for sandbox managers (e.g. Firejail,
>>> Bubblewrap, Flatpack…). In some of these use cases, especially from a
>>> developer point of view, you may want/need to debug your applications
>>> (without requiring to be root). For nested Landlock access-controls
>>> (e.g. container + user session + web browser), it may not be allowed to
>>> create a PID namespace, but you still want to have a meaningful
>>> access-control.
>>>
>>
>> The consideration should be exactly the same as for normal seccomp.
>> If I'm in a container (using PID namespaces + seccomp) and a run a web
>> browser, I can debug the browser.
>>
>> If there's a real use case for adding this type of automatic ptrace
>> protection, then by all means, let's add it as a general seccomp
>> feature.
>>
>
> Right, it makes sense to add this feature to seccomp filters as well.
> What do you think Kees?
>
As a second though, it may be useful for seccomp but it should be
another patch series, independent from this one.
The idea to keep in mind is that this ptrace restriction is an automatic
way to define what is called a subject in common access control
vocabulary, like used by SELinux. A subject should not be able to
impersonate another one with less restrictions (to get more rights).
Because of the stackable restrictions of Landlock (same principle used
by seccomp), it is easy to identify which subject (i.e. group of
processes) is more restricted (or with different restrictions) than
another. This follow the same principle as Yama's ptrace_scope.
Another important argument for a different ptrace-protection
mechanism than seccomp is that Landlock programs may be applied (i.e.
define subject) otherwise than with a process hierarchy. Another way to
define a Landlock subject may be by using cgroups (which was previously
discussed). I'm also thinking about being able to create (real)
capabilities (not to be confused with POSIX capabilities), which may be
useful to implement some parts of Capsicum, by attaching Landlock
programs to a file descriptor (and not directly to a group of
processes). All this to highlight that the ptrace protection is specific
to Landlock and may not be directly shared with seccomp.
Even if Landlock follows the footprints of seccomp, they are different
beasts.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing
From: Mickaël Salaün @ 2018-04-01 22:04 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Tycho Andersen, LKML, Alexei Starovoitov,
Arnaldo Carvalho de Melo, Casey Schaufler, Daniel Borkmann,
David Drysdale, David S . Miller, Eric W . Biederman,
James Morris, Jann Horn, Jonathan Corbet, Michael Kerrisk,
Kees Cook, Paul Moore, Sargun Dhillon, Serge E . Hallyn,
Shuah Khan, Tejun Heo, Thomas Graf, Will Drewry
In-Reply-To: <CALCETrUwkV4_65y7UjSgrq5WHOcZZ=+znKArehvhb1xEGG9HXw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3621 bytes --]
On 03/09/2018 12:53 AM, Andy Lutomirski wrote:
> On Thu, Mar 8, 2018 at 11:51 PM, Mickaël Salaün <mic@digikod.net> wrote:
>>
>> On 07/03/2018 02:21, Andy Lutomirski wrote:
>>> On Tue, Mar 6, 2018 at 11:06 PM, Mickaël Salaün <mic@digikod.net> wrote:
>>>>
>>>> On 06/03/2018 23:46, Tycho Andersen wrote:
>>>>> On Tue, Mar 06, 2018 at 10:33:17PM +0000, Andy Lutomirski wrote:
>>>>>>>> Suppose I'm writing a container manager. I want to run "mount" in the
>>>>>>>> container, but I don't want to allow moun() in general and I want to
>>>>>>>> emulate certain mount() actions. I can write a filter that catches
>>>>>>>> mount using seccomp and calls out to the container manager for help.
>>>>>>>> This isn't theoretical -- Tycho wants *exactly* this use case to be
>>>>>>>> supported.
>>>>>>>
>>>>>>> Well, I think this use case should be handled with something like
>>>>>>> LD_PRELOAD and a helper library. FYI, I did something like this:
>>>>>>> https://github.com/stemjail/stemshim
>>>>>>
>>>>>> I doubt that will work for containers. Containers that use user
>>>>>> namespaces and, for example, setuid programs aren't going to honor
>>>>>> LD_PRELOAD.
>>>>>
>>>>> Or anything that calls syscalls directly, like go programs.
>>>>
>>>> That's why the vDSO-like approach. Enforcing an access control is not
>>>> the issue here, patching a buggy userland (without patching its code) is
>>>> the issue isn't it?
>>>>
>>>> As far as I remember, the main problem is to handle file descriptors
>>>> while "emulating" the kernel behavior. This can be done with a "shim"
>>>> code mapped in every processes. Chrome used something like this (in a
>>>> previous sandbox mechanism) as a kind of emulation (with the current
>>>> seccomp-bpf ). I think it should be doable to replace the (userland)
>>>> emulation code with an IPC wrapper receiving file descriptors through
>>>> UNIX socket.
>>>>
>>>
>>> Can you explain exactly what you mean by "vDSO-like"?
>>>
>>> When a 64-bit program does a syscall, it just executes the SYSCALL
>>> instruction. The vDSO isn't involved at all. 32-bit programs usually
>>> go through the vDSO, but not always.
>>>
>>> It could be possible to force-load a DSO into an entire container and
>>> rig up seccomp to intercept all SYSCALLs not originating from the DSO
>>> such that they merely redirect control to the DSO, but that seems
>>> quite messy.
>>
>> vDSO is a code mapped for all processes. As you said, these processes
>> may use it or not. What I was thinking about is to use the same concept,
>> i.e. map a "shim" code into each processes pertaining to a particular
>> hierarchy (the same way seccomp filters are inherited across processes).
>> With a seccomp filter matching some syscall (e.g. mount, open), it is
>> possible to jump back to the shim code thanks to SECCOMP_RET_TRAP. This
>> shim code should then be able to emulate/patch what is needed, even
>> faking a file opening by receiving a file descriptor through a UNIX
>> socket. As did the Chrome sandbox, the seccomp filter may look at the
>> calling address to allow the shim code to call syscalls without being
>> catched, if needed. However, relying on SIGSYS may not fit with
>> arbitrary code. Using a new SECCOMP_RET_EMULATE (?) may be used to jump
>> to a specific process address, to emulate the syscall in an easier way
>> than only relying on a {c,e}BPF program.
>>
>
> This could indeed be done, but I think that Tycho's approach is much
> cleaner and probably faster.
>
I like it too but how does this handle file descriptors?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)
From: Alan Cox @ 2018-04-01 16:13 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Peter Zijlstra, Paul E . McKenney, Boqun Feng, Andy Lutomirski,
Dave Watson, linux-kernel, linux-api, Paul Turner, Andrew Morton,
Russell King, Thomas Gleixner, Ingo Molnar, H . Peter Anvin,
Andrew Hunter, Andi Kleen, Chris Lameter, Ben Maurer,
Steven Rostedt, Josh Triplett, Linus Torvalds, Catalin Marinas
In-Reply-To: <20180327160542.28457-3-mathieu.desnoyers@efficios.com>
On Tue, 27 Mar 2018 12:05:23 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> Expose a new system call allowing each thread to register one userspace
> memory area to be used as an ABI between kernel and user-space for two
> purposes: user-space restartable sequences and quick access to read the
> current CPU number value from user-space.
What is the *worst* case timing achievable by using the atomics ? What
does it do to real time performance requirements ? For cpu_opv you now
give an answer but your answer is assuming there isn't another thread
actively thrashing the cache or store buffers, and that the user didn't
sneakily pass in a page of uncacheable memory (eg framebuffer, or GPU
space).
I don't see anything that restricts it to cached pages. With that check
in place for x86 at least it would probably be ok and I think the sneaky
attacks to make it uncacheable would fail becuase you've got the pages
locked so trying to give them to an accelerator will block until you are
done.
I still like the idea it's just the latencies concern me.
> Restartable sequences are atomic with respect to preemption
> (making it atomic with respect to other threads running on the
> same CPU), as well as signal delivery (user-space execution
> contexts nested over the same thread).
CPU generally means 'big lump with legs on it'. You are not atomic to the
same CPU, because that CPU may have 30+ cores with 8 threads per core.
It could do with some better terminology (hardware thread, CPU context ?)
> In a typical usage scenario, the thread registering the rseq
> structure will be performing loads and stores from/to that
> structure. It is however also allowed to read that structure
> from other threads. The rseq field updates performed by the
> kernel provide relaxed atomicity semantics, which guarantee
> that other threads performing relaxed atomic reads of the cpu
> number cache will always observe a consistent value.
So what happens to your API if the kernel atomics get improved ? You are
effectively exporting rseq behaviour from private to public.
Alan
^ permalink raw reply
* Re: [REVIEW][PATCH 12/11] ipc: Directly call the security hook in ipc_ops.associate
From: James Morris @ 2018-03-31 2:13 UTC (permalink / raw)
To: Eric W. Biederman
Cc: jannh-hpIqsD4AKlfQT0dZR+AlfA, khlebnikov-XoJtRXgx1JseBXzfvpsJ4g,
linux-api-u79uwXL29TY76Z2rM5mHXA, Linux Containers,
serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA, oleg-H+wXaHxf7aLQT0dZR+AlfA,
esyr-H+wXaHxf7aLQT0dZR+AlfA, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
luto-DgEjT+Ai2ygdnm+yROfE0A,
prakash.sangappa-QHcLZuEGTsvQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, Nagarathnam Muthusamy,
Pavel Emelyanov
In-Reply-To: <877eq2m3or.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Sat, 24 Mar 2018, Eric W. Biederman wrote:
>
> After the last round of cleanups the shm, sem, and msg associate
> operations just became trivial wrappers around the appropriate security
> method. Simplify things further by just calling the security method
> directly.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Reviewed-by: James Morris <james.morris-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
--
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
^ permalink raw reply
* Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces
From: Davidlohr Bueso @ 2018-03-30 20:45 UTC (permalink / raw)
To: Eric W. Biederman
Cc: manfred, Linux Containers, linux-kernel, linux-api, khlebnikov,
prakash.sangappa, luto, akpm, oleg, serge.hallyn, esyr, jannh,
linux-security-module, Pavel Emelyanov, Nagarathnam Muthusamy
In-Reply-To: <87y3i91fxh.fsf@xmission.com>
On Fri, 30 Mar 2018, Eric W. Biederman wrote:
>Davidlohr Bueso <dave@stgolabs.net> writes:
>
>> I ran this on a 40-core (no ht) Westmere with two benchmarks. The first
>> is Manfred's sysvsem lockunlock[1] program which uses _processes_ to,
>> well, lock and unlock the semaphore. The options are a little
>> unconventional, to keep the "critical region small" and the lock+unlock
>> frequency high I added busy_in=busy_out=10. Similarly, to get the
>> worst case scenario and have everyone update the same semaphore, a single
>> one is used. Here are the results (pretty low stddev from run to run)
>> for doing 100,000 lock+unlock.
>>
>> - 1 proc:
>> * vanilla
>> total execution time: 0.110638 seconds for 100000 loops
>> * dirty
>> total execution time: 0.120144 seconds for 100000 loops
>>
>> - 2 proc:
>> * vanilla
>> total execution time: 0.379756 seconds for 100000 loops
>> * dirty
>> total execution time: 0.477778 seconds for 100000 loops
>>
>> - 4 proc:
>> * vanilla
>> total execution time: 6.749710 seconds for 100000 loops
>> * dirty
>> total execution time: 4.651872 seconds for 100000 loops
>>
>> - 8 proc:
>> * vanilla
>> total execution time: 5.558404 seconds for 100000 loops
>> * dirty
>> total execution time: 7.143329 seconds for 100000 loops
>>
>> - 16 proc:
>> * vanilla
>> total execution time: 9.016398 seconds for 100000 loops
>> * dirty
>> total execution time: 9.412055 seconds for 100000 loops
>>
>> - 32 proc:
>> * vanilla
>> total execution time: 9.694451 seconds for 100000 loops
>> * dirty
>> total execution time: 9.990451 seconds for 100000 loops
>>
>> - 64 proc:
>> * vanilla
>> total execution time: 9.844984 seconds for 100032 loops
>> * dirty
>> total execution time: 10.016464 seconds for 100032 loops
>>
>> Lower task counts show pretty massive performance hits of ~9%, ~25%
>> and ~30% for single, two and four/eight processes. As more are added
>> I guess the overhead tends to disappear as for one you have a lot
>> more locking contention going on.
>
>Can you check your notes on the 4 process case? As I read the 4 process
>case above it is ~30% improvement. Either that is a typo or there is the
>potential for quite a bit of noise in the test case.
Yeah, sorry that was a typo. Unlike the second benchmark I didn't have
this one automated but it's always the vanilla kernel that outperforms
the dirty.
Thanks,
Davidlohr
^ permalink raw reply
* Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces
From: Eric W. Biederman @ 2018-03-30 20:12 UTC (permalink / raw)
To: Davidlohr Bueso
Cc: manfred, Linux Containers, linux-kernel, linux-api, khlebnikov,
prakash.sangappa, luto, akpm, oleg, serge.hallyn, esyr, jannh,
linux-security-module, Pavel Emelyanov, Nagarathnam Muthusamy
In-Reply-To: <20180330190951.nfcdwuzp42bl2lfy@linux-n805>
Davidlohr Bueso <dave@stgolabs.net> writes:
> I ran this on a 40-core (no ht) Westmere with two benchmarks. The first
> is Manfred's sysvsem lockunlock[1] program which uses _processes_ to,
> well, lock and unlock the semaphore. The options are a little
> unconventional, to keep the "critical region small" and the lock+unlock
> frequency high I added busy_in=busy_out=10. Similarly, to get the
> worst case scenario and have everyone update the same semaphore, a single
> one is used. Here are the results (pretty low stddev from run to run)
> for doing 100,000 lock+unlock.
>
> - 1 proc:
> * vanilla
> total execution time: 0.110638 seconds for 100000 loops
> * dirty
> total execution time: 0.120144 seconds for 100000 loops
>
> - 2 proc:
> * vanilla
> total execution time: 0.379756 seconds for 100000 loops
> * dirty
> total execution time: 0.477778 seconds for 100000 loops
>
> - 4 proc:
> * vanilla
> total execution time: 6.749710 seconds for 100000 loops
> * dirty
> total execution time: 4.651872 seconds for 100000 loops
>
> - 8 proc:
> * vanilla
> total execution time: 5.558404 seconds for 100000 loops
> * dirty
> total execution time: 7.143329 seconds for 100000 loops
>
> - 16 proc:
> * vanilla
> total execution time: 9.016398 seconds for 100000 loops
> * dirty
> total execution time: 9.412055 seconds for 100000 loops
>
> - 32 proc:
> * vanilla
> total execution time: 9.694451 seconds for 100000 loops
> * dirty
> total execution time: 9.990451 seconds for 100000 loops
>
> - 64 proc:
> * vanilla
> total execution time: 9.844984 seconds for 100032 loops
> * dirty
> total execution time: 10.016464 seconds for 100032 loops
>
> Lower task counts show pretty massive performance hits of ~9%, ~25%
> and ~30% for single, two and four/eight processes. As more are added
> I guess the overhead tends to disappear as for one you have a lot
> more locking contention going on.
Can you check your notes on the 4 process case? As I read the 4 process
case above it is ~30% improvement. Either that is a typo or there is the
potential for quite a bit of noise in the test case.
Eric
^ permalink raw reply
* Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces
From: Davidlohr Bueso @ 2018-03-30 19:09 UTC (permalink / raw)
To: Eric W. Biederman, manfred
Cc: Linux Containers, linux-kernel, linux-api, khlebnikov,
prakash.sangappa, luto, akpm, oleg, serge.hallyn, esyr, jannh,
linux-security-module, Pavel Emelyanov, Nagarathnam Muthusamy
In-Reply-To: <20180329005209.fnzr3hzvyr4oy3wi@linux-n805>
On Wed, 28 Mar 2018, Davidlohr Bueso wrote:
>On Fri, 23 Mar 2018, Eric W. Biederman wrote:
>
>>Today the last process to update a semaphore is remembered and
>>reported in the pid namespace of that process. If there are processes
>>in any other pid namespace querying that process id with GETPID the
>>result will be unusable nonsense as it does not make any
>>sense in your own pid namespace.
>
>Yeah that sounds pretty wrong.
>
>>
>>Due to ipc_update_pid I don't think you will be able to get System V
>>ipc semaphores into a troublesome cache line ping-pong. Using struct
>>pids from separate process are not a problem because they do not share
>>a cache line. Using struct pid from different threads of the same
>>process are unlikely to be a problem as the reference count update
>>can be avoided.
>>
>>Further linux futexes are a much better tool for the job of mutual
>>exclusion between processes than System V semaphores. So I expect
>>programs that are performance limited by their interprocess mutual
>>exclusion primitive will be using futexes.
>
>You would be wrong. There are plenty of real workloads out there
>that do not use futexes and are care about performance; in the end
>futexes are only good for the uncontended cases, it can also
>destroy numa boxes if you consider the global hash table. Experience
>as shown me that sysvipc sems are quite still used.
>
>>
>>So while it is possible that enhancing the storage of the last
>>rocess of a System V semaphore from an integer to a struct pid
>>will cause a performance regression because of the effect
>>of frequently updating the pid reference count. I don't expect
>>that to happen in practice.
>
>How's that? Now thanks to ipc_update_pid() for each semop the user
>passes, perform_atomic_semop() will do two atomic updates for the
>cases where there are multiple processes updating the sem. This is
>not uncommon.
>
>Could you please provide some numbers.
I ran this on a 40-core (no ht) Westmere with two benchmarks. The first
is Manfred's sysvsem lockunlock[1] program which uses _processes_ to,
well, lock and unlock the semaphore. The options are a little
unconventional, to keep the "critical region small" and the lock+unlock
frequency high I added busy_in=busy_out=10. Similarly, to get the
worst case scenario and have everyone update the same semaphore, a single
one is used. Here are the results (pretty low stddev from run to run)
for doing 100,000 lock+unlock.
- 1 proc:
* vanilla
total execution time: 0.110638 seconds for 100000 loops
* dirty
total execution time: 0.120144 seconds for 100000 loops
- 2 proc:
* vanilla
total execution time: 0.379756 seconds for 100000 loops
* dirty
total execution time: 0.477778 seconds for 100000 loops
- 4 proc:
* vanilla
total execution time: 6.749710 seconds for 100000 loops
* dirty
total execution time: 4.651872 seconds for 100000 loops
- 8 proc:
* vanilla
total execution time: 5.558404 seconds for 100000 loops
* dirty
total execution time: 7.143329 seconds for 100000 loops
- 16 proc:
* vanilla
total execution time: 9.016398 seconds for 100000 loops
* dirty
total execution time: 9.412055 seconds for 100000 loops
- 32 proc:
* vanilla
total execution time: 9.694451 seconds for 100000 loops
* dirty
total execution time: 9.990451 seconds for 100000 loops
- 64 proc:
* vanilla
total execution time: 9.844984 seconds for 100032 loops
* dirty
total execution time: 10.016464 seconds for 100032 loops
Lower task counts show pretty massive performance hits of ~9%, ~25%
and ~30% for single, two and four/eight processes. As more are added
I guess the overhead tends to disappear as for one you have a lot
more locking contention going on.
The second workload I ran this patch on was Chris Mason's sem-scalebench[2]
program which uses _threads_ for the sysvsem option (this benchmark is more
about semaphores as a concept rather than sysvsem specific). Dealing with
a single semaphore and increasing thread counts we get:
sembench-sem
vanill dirt
vanilla dirty
Hmean sembench-sem-2 286272.00 ( 0.00%) 288232.00 ( 0.68%)
Hmean sembench-sem-8 510966.00 ( 0.00%) 494375.00 ( -3.25%)
Hmean sembench-sem-12 435753.00 ( 0.00%) 465328.00 ( 6.79%)
Hmean sembench-sem-21 448144.00 ( 0.00%) 462091.00 ( 3.11%)
Hmean sembench-sem-30 479519.00 ( 0.00%) 471295.00 ( -1.72%)
Hmean sembench-sem-48 533270.00 ( 0.00%) 542525.00 ( 1.74%)
Hmean sembench-sem-79 510218.00 ( 0.00%) 528392.00 ( 3.56%)
Unsurprisingly, the thread case shows no overhead -- and yes, even better at
times but still noise). Similarly, when completely abusing the systems and doing
64*NCPUS there is pretty much no difference:
vanill dirt
vanilla dirty
User 1865.99 1819.75
System 35080.97 35396.34
Elapsed 3602.03 3560.50
So at least for a large box this patch hurts the cases where there is low
to medium cpu usage (no more than ~8 processes on a 40 core box) in a non
trivial way. For more processes it doesn't matter. We can confirm that the
case for threads is irrelevant. While I'm not happy about the 30% regression
I guess we can live with this.
Manfred, any thoughts?
Thanks
Davidlohr
[1] https://github.com/manfred-colorfu/ipcscale/blob/master/sem-lockunlock.c
[2] https://github.com/davidlohr/sembench-ng/blob/master/sembench.c
^ permalink raw reply
* [PATCH 32/32] random: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
The big change is that random_read_wait and random_write_wait are merged
into a single waitqueue that uses keyed wakeups. Because wait_event_*
doesn't know about that this will lead to occassional spurious wakeups
in _random_read and add_hwgenerator_randomness, but wait_event_* is
designed to handle these and were are not in a a hot path there.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/random.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index e5b3d3ba4660..840d80b64431 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -401,8 +401,7 @@ static struct poolinfo {
/*
* Static global variables
*/
-static DECLARE_WAIT_QUEUE_HEAD(random_read_wait);
-static DECLARE_WAIT_QUEUE_HEAD(random_write_wait);
+static DECLARE_WAIT_QUEUE_HEAD(random_wait);
static struct fasync_struct *fasync;
static DEFINE_SPINLOCK(random_ready_list_lock);
@@ -710,7 +709,7 @@ static void credit_entropy_bits(struct entropy_store *r, int nbits)
/* should we wake readers? */
if (entropy_bits >= random_read_wakeup_bits) {
- wake_up_interruptible(&random_read_wait);
+ wake_up_interruptible_poll(&random_wait, POLLIN);
kill_fasync(&fasync, SIGIO, POLL_IN);
}
/* If the input pool is getting full, send some
@@ -1293,7 +1292,7 @@ static size_t account(struct entropy_store *r, size_t nbytes, int min,
trace_debit_entropy(r->name, 8 * ibytes);
if (ibytes &&
(r->entropy_count >> ENTROPY_SHIFT) < random_write_wakeup_bits) {
- wake_up_interruptible(&random_write_wait);
+ wake_up_interruptible_poll(&random_wait, POLLOUT);
kill_fasync(&fasync, SIGIO, POLL_OUT);
}
@@ -1748,7 +1747,7 @@ _random_read(int nonblock, char __user *buf, size_t nbytes)
if (nonblock)
return -EAGAIN;
- wait_event_interruptible(random_read_wait,
+ wait_event_interruptible(random_wait,
ENTROPY_BITS(&input_pool) >=
random_read_wakeup_bits);
if (signal_pending(current))
@@ -1784,14 +1783,17 @@ urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
return ret;
}
+static struct wait_queue_head *
+random_get_poll_head(struct file *file, __poll_t events)
+{
+ return &random_wait;
+}
+
static __poll_t
-random_poll(struct file *file, poll_table * wait)
+random_poll_mask(struct file *file, __poll_t events)
{
- __poll_t mask;
+ __poll_t mask = 0;
- poll_wait(file, &random_read_wait, wait);
- poll_wait(file, &random_write_wait, wait);
- mask = 0;
if (ENTROPY_BITS(&input_pool) >= random_read_wakeup_bits)
mask |= EPOLLIN | EPOLLRDNORM;
if (ENTROPY_BITS(&input_pool) < random_write_wakeup_bits)
@@ -1890,7 +1892,8 @@ static int random_fasync(int fd, struct file *filp, int on)
const struct file_operations random_fops = {
.read = random_read,
.write = random_write,
- .poll = random_poll,
+ .get_poll_head = random_get_poll_head,
+ .poll_mask = random_poll_mask,
.unlocked_ioctl = random_ioctl,
.fasync = random_fasync,
.llseek = noop_llseek,
@@ -2223,7 +2226,7 @@ void add_hwgenerator_randomness(const char *buffer, size_t count,
* We'll be woken up again once below random_write_wakeup_thresh,
* or when the calling thread is about to terminate.
*/
- wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+ wait_event_interruptible(random_wait, kthread_should_stop() ||
ENTROPY_BITS(&input_pool) <= random_write_wakeup_bits);
mix_pool_bytes(poolp, buffer, count);
credit_entropy_bits(poolp, entropy);
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 31/32] timerfd: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/timerfd.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index cdad49da3ff7..d84a2bee4f82 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -226,21 +226,20 @@ static int timerfd_release(struct inode *inode, struct file *file)
kfree_rcu(ctx, rcu);
return 0;
}
-
-static __poll_t timerfd_poll(struct file *file, poll_table *wait)
+
+static struct wait_queue_head *timerfd_get_poll_head(struct file *file,
+ __poll_t eventmask)
{
struct timerfd_ctx *ctx = file->private_data;
- __poll_t events = 0;
- unsigned long flags;
- poll_wait(file, &ctx->wqh, wait);
+ return &ctx->wqh;
+}
- spin_lock_irqsave(&ctx->wqh.lock, flags);
- if (ctx->ticks)
- events |= EPOLLIN;
- spin_unlock_irqrestore(&ctx->wqh.lock, flags);
+static __poll_t timerfd_poll_mask(struct file *file, __poll_t eventmask)
+{
+ struct timerfd_ctx *ctx = file->private_data;
- return events;
+ return ctx->ticks ? EPOLLIN : 0;
}
static ssize_t timerfd_read(struct file *file, char __user *buf, size_t count,
@@ -364,7 +363,8 @@ static long timerfd_ioctl(struct file *file, unsigned int cmd, unsigned long arg
static const struct file_operations timerfd_fops = {
.release = timerfd_release,
- .poll = timerfd_poll,
+ .get_poll_head = timerfd_get_poll_head,
+ .poll_mask = timerfd_poll_mask,
.read = timerfd_read,
.llseek = noop_llseek,
.show_fdinfo = timerfd_show,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 30/32] eventfd: switch to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/eventfd.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 012f5bd46dfa..d70b4907f978 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -101,14 +101,20 @@ static int eventfd_release(struct inode *inode, struct file *file)
return 0;
}
-static __poll_t eventfd_poll(struct file *file, poll_table *wait)
+static struct wait_queue_head *
+eventfd_get_poll_head(struct file *file, __poll_t events)
+{
+ struct eventfd_ctx *ctx = file->private_data;
+
+ return &ctx->wqh;
+}
+
+static __poll_t eventfd_poll_mask(struct file *file, __poll_t eventmask)
{
struct eventfd_ctx *ctx = file->private_data;
__poll_t events = 0;
u64 count;
- poll_wait(file, &ctx->wqh, wait);
-
/*
* All writes to ctx->count occur within ctx->wqh.lock. This read
* can be done outside ctx->wqh.lock because we know that poll_wait
@@ -305,7 +311,8 @@ static const struct file_operations eventfd_fops = {
.show_fdinfo = eventfd_show_fdinfo,
#endif
.release = eventfd_release,
- .poll = eventfd_poll,
+ .get_poll_head = eventfd_get_poll_head,
+ .poll_mask = eventfd_poll_mask,
.read = eventfd_read,
.write = eventfd_write,
.llseek = noop_llseek,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 29/32] pipe: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/pipe.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index 7b1954caf388..81937590ea0a 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -509,19 +509,22 @@ static long pipe_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
}
}
-/* No kernel lock held - fine */
-static __poll_t
-pipe_poll(struct file *filp, poll_table *wait)
+static struct wait_queue_head *
+pipe_get_poll_head(struct file *filp, __poll_t events)
{
- __poll_t mask;
struct pipe_inode_info *pipe = filp->private_data;
- int nrbufs;
- poll_wait(filp, &pipe->wait, wait);
+ return &pipe->wait;
+}
+
+/* No kernel lock held - fine */
+static __poll_t pipe_poll_mask(struct file *filp, __poll_t events)
+{
+ struct pipe_inode_info *pipe = filp->private_data;
+ int nrbufs = pipe->nrbufs;
+ __poll_t mask = 0;
/* Reading only -- no need for acquiring the semaphore. */
- nrbufs = pipe->nrbufs;
- mask = 0;
if (filp->f_mode & FMODE_READ) {
mask = (nrbufs > 0) ? EPOLLIN | EPOLLRDNORM : 0;
if (!pipe->writers && filp->f_version != pipe->w_counter)
@@ -1015,7 +1018,8 @@ const struct file_operations pipefifo_fops = {
.llseek = no_llseek,
.read_iter = pipe_read,
.write_iter = pipe_write,
- .poll = pipe_poll,
+ .get_poll_head = pipe_get_poll_head,
+ .poll_mask = pipe_poll_mask,
.unlocked_ioctl = pipe_ioctl,
.release = pipe_release,
.fasync = pipe_fasync,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 28/32] crypto: af_alg: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
crypto/af_alg.c | 13 +++----------
crypto/algif_aead.c | 4 ++--
crypto/algif_skcipher.c | 4 ++--
include/crypto/if_alg.h | 3 +--
4 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 50d75de539f5..330aef1cd08b 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -1060,19 +1060,12 @@ void af_alg_async_cb(struct crypto_async_request *_req, int err)
}
EXPORT_SYMBOL_GPL(af_alg_async_cb);
-/**
- * af_alg_poll - poll system call handler
- */
-__poll_t af_alg_poll(struct file *file, struct socket *sock,
- poll_table *wait)
+__poll_t af_alg_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct af_alg_ctx *ctx = ask->private;
- __poll_t mask;
-
- sock_poll_wait(file, sk_sleep(sk), wait);
- mask = 0;
+ __poll_t mask = 0;
if (!ctx->more || ctx->used)
mask |= EPOLLIN | EPOLLRDNORM;
@@ -1082,7 +1075,7 @@ __poll_t af_alg_poll(struct file *file, struct socket *sock,
return mask;
}
-EXPORT_SYMBOL_GPL(af_alg_poll);
+EXPORT_SYMBOL_GPL(af_alg_poll_mask);
/**
* af_alg_alloc_areq - allocate struct af_alg_async_req
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 4b07edd5a9ff..330cf9f2b767 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -375,7 +375,7 @@ static struct proto_ops algif_aead_ops = {
.sendmsg = aead_sendmsg,
.sendpage = af_alg_sendpage,
.recvmsg = aead_recvmsg,
- .poll = af_alg_poll,
+ .poll_mask = af_alg_poll_mask,
};
static int aead_check_key(struct socket *sock)
@@ -471,7 +471,7 @@ static struct proto_ops algif_aead_ops_nokey = {
.sendmsg = aead_sendmsg_nokey,
.sendpage = aead_sendpage_nokey,
.recvmsg = aead_recvmsg_nokey,
- .poll = af_alg_poll,
+ .poll_mask = af_alg_poll_mask,
};
static void *aead_bind(const char *name, u32 type, u32 mask)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index c4e885df4564..15cf3c5222e0 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -205,7 +205,7 @@ static struct proto_ops algif_skcipher_ops = {
.sendmsg = skcipher_sendmsg,
.sendpage = af_alg_sendpage,
.recvmsg = skcipher_recvmsg,
- .poll = af_alg_poll,
+ .poll_mask = af_alg_poll_mask,
};
static int skcipher_check_key(struct socket *sock)
@@ -301,7 +301,7 @@ static struct proto_ops algif_skcipher_ops_nokey = {
.sendmsg = skcipher_sendmsg_nokey,
.sendpage = skcipher_sendpage_nokey,
.recvmsg = skcipher_recvmsg_nokey,
- .poll = af_alg_poll,
+ .poll_mask = af_alg_poll_mask,
};
static void *skcipher_bind(const char *name, u32 type, u32 mask)
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 482461d8931d..cc414db9da0a 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -245,8 +245,7 @@ ssize_t af_alg_sendpage(struct socket *sock, struct page *page,
int offset, size_t size, int flags);
void af_alg_free_resources(struct af_alg_async_req *areq);
void af_alg_async_cb(struct crypto_async_request *_req, int err);
-__poll_t af_alg_poll(struct file *file, struct socket *sock,
- poll_table *wait);
+__poll_t af_alg_poll_mask(struct socket *sock, __poll_t events);
struct af_alg_async_req *af_alg_alloc_areq(struct sock *sk,
unsigned int areqlen);
int af_alg_get_rsgl(struct sock *sk, struct msghdr *msg, int flags,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 27/32] net/rxrpc: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
net/rxrpc/af_rxrpc.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 0c9c18aa7c77..d2440d5c3ce8 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -729,15 +729,11 @@ static int rxrpc_getsockopt(struct socket *sock, int level, int optname,
/*
* permit an RxRPC socket to be polled
*/
-static __poll_t rxrpc_poll(struct file *file, struct socket *sock,
- poll_table *wait)
+static __poll_t rxrpc_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
struct rxrpc_sock *rx = rxrpc_sk(sk);
- __poll_t mask;
-
- sock_poll_wait(file, sk_sleep(sk), wait);
- mask = 0;
+ __poll_t mask = 0;
/* the socket is readable if there are any messages waiting on the Rx
* queue */
@@ -940,7 +936,7 @@ static const struct proto_ops rxrpc_rpc_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = sock_no_getname,
- .poll = rxrpc_poll,
+ .poll_mask = rxrpc_poll_mask,
.ioctl = sock_no_ioctl,
.listen = rxrpc_listen,
.shutdown = rxrpc_shutdown,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 26/32] net/iucv: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/net/iucv/af_iucv.h | 2 --
net/iucv/af_iucv.c | 7 ++-----
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/include/net/iucv/af_iucv.h b/include/net/iucv/af_iucv.h
index f4c21b5a1242..b0eaeb02d46d 100644
--- a/include/net/iucv/af_iucv.h
+++ b/include/net/iucv/af_iucv.h
@@ -153,8 +153,6 @@ struct iucv_sock_list {
atomic_t autobind_name;
};
-__poll_t iucv_sock_poll(struct file *file, struct socket *sock,
- poll_table *wait);
void iucv_sock_link(struct iucv_sock_list *l, struct sock *s);
void iucv_sock_unlink(struct iucv_sock_list *l, struct sock *s);
void iucv_accept_enqueue(struct sock *parent, struct sock *sk);
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 1e8cc7bcbca3..539a312dc481 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -1489,14 +1489,11 @@ static inline __poll_t iucv_accept_poll(struct sock *parent)
return 0;
}
-__poll_t iucv_sock_poll(struct file *file, struct socket *sock,
- poll_table *wait)
+static __poll_t iucv_sock_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
__poll_t mask = 0;
- sock_poll_wait(file, sk_sleep(sk), wait);
-
if (sk->sk_state == IUCV_LISTEN)
return iucv_accept_poll(sk);
@@ -2389,7 +2386,7 @@ static const struct proto_ops iucv_sock_ops = {
.getname = iucv_sock_getname,
.sendmsg = iucv_sock_sendmsg,
.recvmsg = iucv_sock_recvmsg,
- .poll = iucv_sock_poll,
+ .poll_mask = iucv_sock_poll_mask,
.ioctl = sock_no_ioctl,
.mmap = sock_no_mmap,
.socketpair = sock_no_socketpair,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 25/32] net/phonet: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
net/phonet/socket.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/phonet/socket.c b/net/phonet/socket.c
index 28d981512f5f..70ac4539d5b7 100644
--- a/net/phonet/socket.c
+++ b/net/phonet/socket.c
@@ -341,15 +341,12 @@ static int pn_socket_getname(struct socket *sock, struct sockaddr *addr,
return 0;
}
-static __poll_t pn_socket_poll(struct file *file, struct socket *sock,
- poll_table *wait)
+static __poll_t pn_socket_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
struct pep_sock *pn = pep_sk(sk);
__poll_t mask = 0;
- poll_wait(file, sk_sleep(sk), wait);
-
if (sk->sk_state == TCP_CLOSE)
return EPOLLERR;
if (!skb_queue_empty(&sk->sk_receive_queue))
@@ -474,7 +471,7 @@ const struct proto_ops phonet_stream_ops = {
.socketpair = sock_no_socketpair,
.accept = pn_socket_accept,
.getname = pn_socket_getname,
- .poll = pn_socket_poll,
+ .poll_mask = pn_socket_poll_mask,
.ioctl = pn_socket_ioctl,
.listen = pn_socket_listen,
.shutdown = sock_no_shutdown,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 24/32] net/nfc: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
net/nfc/llcp_sock.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index 376040092142..b6010750e634 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -549,16 +549,13 @@ static inline __poll_t llcp_accept_poll(struct sock *parent)
return 0;
}
-static __poll_t llcp_sock_poll(struct file *file, struct socket *sock,
- poll_table *wait)
+static __poll_t llcp_sock_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
__poll_t mask = 0;
pr_debug("%p\n", sk);
- sock_poll_wait(file, sk_sleep(sk), wait);
-
if (sk->sk_state == LLCP_LISTEN)
return llcp_accept_poll(sk);
@@ -900,7 +897,7 @@ static const struct proto_ops llcp_sock_ops = {
.socketpair = sock_no_socketpair,
.accept = llcp_sock_accept,
.getname = llcp_sock_getname,
- .poll = llcp_sock_poll,
+ .poll_mask = llcp_sock_poll_mask,
.ioctl = sock_no_ioctl,
.listen = llcp_sock_listen,
.shutdown = sock_no_shutdown,
@@ -920,7 +917,7 @@ static const struct proto_ops llcp_rawsock_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = llcp_sock_getname,
- .poll = llcp_sock_poll,
+ .poll_mask = llcp_sock_poll_mask,
.ioctl = sock_no_ioctl,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 23/32] net/caif: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:08 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
net/caif/caif_socket.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index a6fb1b3bcad9..c7991867d622 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -934,15 +934,11 @@ static int caif_release(struct socket *sock)
}
/* Copied from af_unix.c:unix_poll(), added CAIF tx_flow handling */
-static __poll_t caif_poll(struct file *file,
- struct socket *sock, poll_table *wait)
+static __poll_t caif_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
- __poll_t mask;
struct caifsock *cf_sk = container_of(sk, struct caifsock, sk);
-
- sock_poll_wait(file, sk_sleep(sk), wait);
- mask = 0;
+ __poll_t mask = 0;
/* exceptional events? */
if (sk->sk_err)
@@ -976,7 +972,7 @@ static const struct proto_ops caif_seqpacket_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = sock_no_getname,
- .poll = caif_poll,
+ .poll_mask = caif_poll_mask,
.ioctl = sock_no_ioctl,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
@@ -997,7 +993,7 @@ static const struct proto_ops caif_stream_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = sock_no_getname,
- .poll = caif_poll,
+ .poll_mask = caif_poll_mask,
.ioctl = sock_no_ioctl,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 22/32] net/bluetooth: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:07 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/net/bluetooth/bluetooth.h | 2 +-
net/bluetooth/af_bluetooth.c | 7 ++-----
net/bluetooth/l2cap_sock.c | 2 +-
net/bluetooth/rfcomm/sock.c | 2 +-
net/bluetooth/sco.c | 2 +-
5 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index ec9d6bc65855..53ce8176c313 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -271,7 +271,7 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
int flags);
int bt_sock_stream_recvmsg(struct socket *sock, struct msghdr *msg,
size_t len, int flags);
-__poll_t bt_sock_poll(struct file *file, struct socket *sock, poll_table *wait);
+__poll_t bt_sock_poll_mask(struct socket *sock, __poll_t events);
int bt_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg);
int bt_sock_wait_state(struct sock *sk, int state, unsigned long timeo);
int bt_sock_wait_ready(struct sock *sk, unsigned long flags);
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 84d92a077834..80033a7e1de2 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -437,16 +437,13 @@ static inline __poll_t bt_accept_poll(struct sock *parent)
return 0;
}
-__poll_t bt_sock_poll(struct file *file, struct socket *sock,
- poll_table *wait)
+__poll_t bt_sock_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
__poll_t mask = 0;
BT_DBG("sock %p, sk %p", sock, sk);
- poll_wait(file, sk_sleep(sk), wait);
-
if (sk->sk_state == BT_LISTEN)
return bt_accept_poll(sk);
@@ -478,7 +475,7 @@ __poll_t bt_sock_poll(struct file *file, struct socket *sock,
return mask;
}
-EXPORT_SYMBOL(bt_sock_poll);
+EXPORT_SYMBOL(bt_sock_poll_mask);
int bt_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
{
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 67a8642f57ea..d20b33daa80f 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1654,7 +1654,7 @@ static const struct proto_ops l2cap_sock_ops = {
.getname = l2cap_sock_getname,
.sendmsg = l2cap_sock_sendmsg,
.recvmsg = l2cap_sock_recvmsg,
- .poll = bt_sock_poll,
+ .poll_mask = bt_sock_poll_mask,
.ioctl = bt_sock_ioctl,
.mmap = sock_no_mmap,
.socketpair = sock_no_socketpair,
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 1aaccf637479..b4dc96481d92 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -1049,7 +1049,7 @@ static const struct proto_ops rfcomm_sock_ops = {
.setsockopt = rfcomm_sock_setsockopt,
.getsockopt = rfcomm_sock_getsockopt,
.ioctl = rfcomm_sock_ioctl,
- .poll = bt_sock_poll,
+ .poll_mask = bt_sock_poll_mask,
.socketpair = sock_no_socketpair,
.mmap = sock_no_mmap
};
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 08df57665e1f..b2bf5c767b3e 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -1198,7 +1198,7 @@ static const struct proto_ops sco_sock_ops = {
.getname = sco_sock_getname,
.sendmsg = sco_sock_sendmsg,
.recvmsg = sco_sock_recvmsg,
- .poll = bt_sock_poll,
+ .poll_mask = bt_sock_poll_mask,
.ioctl = bt_sock_ioctl,
.mmap = sock_no_mmap,
.socketpair = sock_no_socketpair,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 21/32] net/sctp: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:07 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/net/sctp/sctp.h | 3 +--
net/sctp/ipv6.c | 2 +-
net/sctp/protocol.c | 2 +-
net/sctp/socket.c | 4 +---
4 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index f7ae6b0a21d0..37abd5ba4a3f 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -107,8 +107,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb);
int sctp_inet_listen(struct socket *sock, int backlog);
void sctp_write_space(struct sock *sk);
void sctp_data_ready(struct sock *sk);
-__poll_t sctp_poll(struct file *file, struct socket *sock,
- poll_table *wait);
+__poll_t sctp_poll_mask(struct socket *sock, __poll_t events);
void sctp_sock_rfree(struct sk_buff *skb);
void sctp_copy_sock(struct sock *newsk, struct sock *sk,
struct sctp_association *asoc);
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index e35d4f73d2df..6b0b8fc5b75a 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -976,7 +976,7 @@ static const struct proto_ops inet6_seqpacket_ops = {
.socketpair = sock_no_socketpair,
.accept = inet_accept,
.getname = sctp_getname,
- .poll = sctp_poll,
+ .poll_mask = sctp_poll_mask,
.ioctl = inet6_ioctl,
.listen = sctp_inet_listen,
.shutdown = inet_shutdown,
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 91813e686c67..20c544890e80 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1024,7 +1024,7 @@ static const struct proto_ops inet_seqpacket_ops = {
.socketpair = sock_no_socketpair,
.accept = inet_accept,
.getname = inet_getname, /* Semantics are different. */
- .poll = sctp_poll,
+ .poll_mask = sctp_poll_mask,
.ioctl = inet_ioctl,
.listen = sctp_inet_listen,
.shutdown = inet_shutdown, /* Looks harmless. */
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index bf271f8c2dc9..097454740929 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -7587,14 +7587,12 @@ int sctp_inet_listen(struct socket *sock, int backlog)
* here, again, by modeling the current TCP/UDP code. We don't have
* a good way to test with it yet.
*/
-__poll_t sctp_poll(struct file *file, struct socket *sock, poll_table *wait)
+__poll_t sctp_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
struct sctp_sock *sp = sctp_sk(sk);
__poll_t mask;
- poll_wait(file, sk_sleep(sk), wait);
-
sock_rps_record_flow(sk);
/* A TCP-style listening socket becomes readable when the accept queue
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 20/32] net/tipc: convert to ->poll_mask
From: Christoph Hellwig @ 2018-03-30 15:07 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180330150809.28094-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
net/tipc/socket.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 7dfa9fc99ec3..e9c6f185db74 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -695,10 +695,9 @@ static int tipc_getname(struct socket *sock, struct sockaddr *uaddr,
}
/**
- * tipc_poll - read and possibly block on pollmask
+ * tipc_poll - read pollmask
* @file: file structure associated with the socket
* @sock: socket for which to calculate the poll bits
- * @wait: ???
*
* Returns pollmask value
*
@@ -712,15 +711,12 @@ static int tipc_getname(struct socket *sock, struct sockaddr *uaddr,
* imply that the operation will succeed, merely that it should be performed
* and will not block.
*/
-static __poll_t tipc_poll(struct file *file, struct socket *sock,
- poll_table *wait)
+static __poll_t tipc_poll_mask(struct socket *sock, __poll_t events)
{
struct sock *sk = sock->sk;
struct tipc_sock *tsk = tipc_sk(sk);
__poll_t revents = 0;
- sock_poll_wait(file, sk_sleep(sk), wait);
-
if (sk->sk_shutdown & RCV_SHUTDOWN)
revents |= EPOLLRDHUP | EPOLLIN | EPOLLRDNORM;
if (sk->sk_shutdown == SHUTDOWN_MASK)
@@ -3020,7 +3016,7 @@ static const struct proto_ops msg_ops = {
.socketpair = tipc_socketpair,
.accept = sock_no_accept,
.getname = tipc_getname,
- .poll = tipc_poll,
+ .poll_mask = tipc_poll_mask,
.ioctl = tipc_ioctl,
.listen = sock_no_listen,
.shutdown = tipc_shutdown,
@@ -3041,7 +3037,7 @@ static const struct proto_ops packet_ops = {
.socketpair = tipc_socketpair,
.accept = tipc_accept,
.getname = tipc_getname,
- .poll = tipc_poll,
+ .poll_mask = tipc_poll_mask,
.ioctl = tipc_ioctl,
.listen = tipc_listen,
.shutdown = tipc_shutdown,
@@ -3062,7 +3058,7 @@ static const struct proto_ops stream_ops = {
.socketpair = tipc_socketpair,
.accept = tipc_accept,
.getname = tipc_getname,
- .poll = tipc_poll,
+ .poll_mask = tipc_poll_mask,
.ioctl = tipc_ioctl,
.listen = tipc_listen,
.shutdown = tipc_shutdown,
--
2.14.2
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox